I am uploading a worker using `wrangler deploy` and getting this error ` workers.api.error.unknown

I am uploading a worker using

wrangler deploy

wrangler deploy

and getting this error

  workers.api.error.unknown [code: 10013]

  workers.api.error.unknown [code: 10013]

. If I remove

upload_source_maps = true

upload_source_maps = true

from wrangler.toml it starts working correctly. This used to be working before.
Are there any issues with source maps uploads right now?

Walshy•5/17/24, 1:18 PM

cc: @Nevi | Product Manager

avogadroOP•5/17/24, 1:28 PM

I just checked the above and this is not limited to just one worker, its affecting all of our worker deploys. Same symptom, commenting out the

upload_source_maps

upload_source_maps

makes the upload work.

Walshy•5/17/24, 1:31 PM

Raised up to support so they can ping eng

Walshy•5/17/24, 2:55 PM

Incident opened - https://www.cloudflarestatus.com/incidents/8h32p5y03rrr

Cloudflare Workers API Errors

Aavogadro I am uploading a worker using `wrangler deploy` and getting this error ` worker...

avogadroOP•5/18/24, 2:41 PM

This error is back again (It was back to working yesterday).

Aavogadro This error is back again (It was back to working yesterday).

DaniFoldi•5/18/24, 2:49 PM

Let me try and repro

DaniFoldi•5/18/24, 2:50 PM

can repro, let me raise

safah222•5/18/24, 3:41 PM

Hello

safah222•5/18/24, 3:41 PM

How I can trigger WAF rule based on operation system ?? so if i want to block linux for example how I can trigger that

Ssafah222 How I can trigger WAF rule based on operation system ?? so if i want to block li...

arch•5/18/24, 3:49 PM

Short version - you can't. If you're relying on the User Agent, those can easily be changed. (I'd also generally discourage blocking based on a users OS)

safah222•5/18/24, 3:55 PM

how I can block based on user OS ??

zegevlier•5/18/24, 4:12 PM

Look one message up, Arch answered you.

Aavogadro This error is back again (It was back to working yesterday).

DaniFoldi•5/18/24, 5:09 PM

This should be fixed now

sherlock•5/18/24, 7:18 PM

Hi! I'm working on a discord bot that i'm running on workers. The same code executed locally works, but on a worker it gets a CANCELED outcome and I'm struggling to understand why. There's a not of helpful info attached to it, nor am I abel to find any documentation related to it.
What causes the outcome to be CANCELED?

kaneki•5/18/24, 7:19 PM

Hello people, Where to share my open-source project related to workers?

Ssherlock Hi! I'm working on a discord bot that i'm running on workers. The same code exec...

kian•5/18/24, 7:19 PM

Are you using Service Bindings?

Kkaneki Hello people, Where to share my open-source project related to workers? 😅

kian•5/18/24, 7:19 PM

#what-i-built

Kkian #what-i-built

kaneki•5/18/24, 7:19 PM

Yayy thankss

Kkian Are you using Service Bindings?

sherlock•5/18/24, 7:20 PM

I have 2 KV bindings.
EDIT: just educated myself - no, not using any service bindings, but making a few API calls to discord in the lifetime of the request

Ssherlock I have 2 KV bindings. EDIT: just educated myself - no, not using any service bin...

sherlock•5/18/24, 8:30 PM

I think I found out why - I added some waits to retry the rate limited calls, and that increases my CPU time way beyond the free limit of 10ms. (Not the ideal way to do it, I know. I'm exploring Workers so this is fun

)

Unsmart•5/18/24, 8:41 PM

A wait/setTimeout doesnt use CPU time, what does use CPU time is parsing the data from KV (or from the discord api) so the larger the value the more CPU time it uses. Local dev doesnt have any CPU limits thus it works fine no matter the size

Unsmart•5/18/24, 8:42 PM

And KV doesnt really have rate limits so I highly doubt the calls to KV are ever being retried but the 1st call will succeed

sherlock•5/18/24, 8:45 PM

My calls are to a third party api, some manipulation on the data and then create a thread and post multiple messages on that thread. But as you say, IO wait time would be different from CPU time, so I'm back to square one, on why the request gets cancelled before I return a response :/

Walshy•5/18/24, 9:17 PM

also canceled is not due to cpu limits

Walshy•5/18/24, 9:17 PM

canceled means the client cancelled the request

Walshy•5/18/24, 9:17 PM

so your Worker took too long to respond and the request was cancelled

Walshy•5/18/24, 9:17 PM

if you're using interactions, they have a pretty fixed time to respond unless you defer

Walshy•5/18/24, 9:18 PM

waiting for these apis and things all add to that wall time limit imposed on you

Walshy•5/18/24, 9:18 PM

i'd recommend deferring and responding when you can

Kkian .dev.vars is just for local development

Baran•5/18/24, 9:28 PM

can I not add secrets in

.dev.vars

.dev.vars

file to

wrangler.toml

wrangler.toml

?

Something like this:

name = "TBA"
compatibility_date = "2024-05-12"
compatibility_flags = ["nodejs_compat"]
pages_build_output_dir = ".vercel/output/static"

[vars]
TURSO_DATABASE_URL = "libsql://TBA.turso.io"
TURSO_AUTH_TOKEN = "TBA"

[.dev.vars]
TURSO_DATABASE_URL = "http://127.0.0.1:8080"
TURSO_AUTH_TOKEN = "TBA"

name = "TBA"
compatibility_date = "2024-05-12"
compatibility_flags = ["nodejs_compat"]
pages_build_output_dir = ".vercel/output/static"

[vars]
TURSO_DATABASE_URL = "libsql://TBA.turso.io"
TURSO_AUTH_TOKEN = "TBA"

[.dev.vars]
TURSO_DATABASE_URL = "http://127.0.0.1:8080"
TURSO_AUTH_TOKEN = "TBA"

kian•5/18/24, 9:28 PM

[vars]

[vars]

shouldn't contain secrets.

Baran•5/18/24, 9:29 PM

why?

kian•5/18/24, 9:29 PM

Because that's what secrets are for. They can't be seen in the dashboard and aren't in files that you commit to VCS (like Wrangler.toml)

kian•5/18/24, 9:30 PM

It's a shouldn't, not a can't - if you really want to you can but it isn't best practice.

Baran•5/18/24, 9:30 PM

so what is the alternative?

kian•5/18/24, 9:30 PM

The message you replied to is in the conversation that explains it

kian•5/18/24, 9:31 PM

.dev.vars for local development, and secrets for production

Walshy•5/18/24, 9:31 PM

(wrangler secret putwrangler secret put to upload a secret for prod)

Baran•5/18/24, 9:41 PM

environment variables are:

variables that get set to different values based on the code's environment that is running on.
plain text (and visible on the dashboard) or encrypted (and not visible on the dashboard).
also known as "binding"s.

secrets are a type of environment variables that are encrypted and not visible on the dashboard. They are set via WranglerWrangler

Baran•5/18/24, 9:41 PM

is my understanding correct?

YokoWasis•5/19/24, 2:41 AM

Anyone here use Argo smart routing with workers? My workers throwing CORS error. When I open the url from browser.

When I change it to argo smart routing, it suddenly has captcha, probably that's the reason.

Any idea how to fix this?

Edit :
Turns out my domain is set to "under attack" a few years back.

matt•5/19/24, 7:30 AM

are there any ways to avoid having to drill the

env

env

parameter through all the functions? i know you can't do something like const secret = process.env.MY_SECRETconst secret = process.env.MY_SECRET at the top of a file and have it work like a node server, but surely there must be some other way to read from env without all this drilling

matt•5/19/24, 7:31 AM

maybe something with AsyncLocalStorage?

matt•5/19/24, 7:34 AM

I guess i could use esbuild --define to replace process.env.Xprocess.env.X during the build, but probably not a good idea to do that with secrets. i wonder what other options there are

Mmatt maybe something with AsyncLocalStorage?

Hello, I’m Allie!•5/19/24, 7:42 AM

ALS is a good choice there

Hello, I’m Allie!•5/19/24, 7:42 AM

Though as you noted, you need to make sure it isn’t called directly in the global scope

I am uploading a worker using `wrangler deploy` and getting this error ` workers.api.error.unknown

Similar Threads

Similar Threads

Similar Threads