If you don’t use waitUntil, then as long as you receive a response, the Worker will have completed i
If you don’t use waitUntil, then as long as you receive a response, the Worker will have completed its task
MI don't use waitUntil. The thing is I could not reproduce the issue yet when I had logs trailing with wrangler. The only thing I see is that the last API call did not happen. But is there any way to see this in the cloudflare logs to be certain this is actually the issue?
HDoes it happen if you run it locally with wrangler?
HYou could also log the API response to see that it does go through
DI wanted to put the Worker in the US region so I wouldn't get billed for non-US traffic from Google Cloud Run lol
HIf it is GeoIP-based, then it should always be US anyway
HThough, can't you just prevent Cloud Run from booting anywhere other than the US?
MWill try to do, but is it the only way to find out if my execution was terminated early?
HAssuming that the logs don't show an error, then I don't think it would be getting cut off. Might be something else being skipped in the code
HIf the request goes through, then it has completed execution, so maybe there are some conditions for an API call that aren't being fulfilled
DCloud Run is booting only in the US. The thing is if the Worker is running outside of the US, the subrequest to Cloud Run is gonna be outside the US for bandwidth billing purposes, no?
HUh... I'm not actually sure how they determine the "region" it is egressing to, and thus the bill. If it is based on IP geolocation, then all Workers should appear as being from the US
HAs for your original question, if Argo detects that an "origin" is in the US, it will spawn itself there. This does require more than one request per Worker invocation though
II believe Cloud Run uses anycast for their URLs
IAnd then they'd bill based on the DC ingressed at
Dwhatttt. lemme check that!
IIf not then I can't imagine how they bill based on region, GeoIP wouldn't be accurate enough for billing purposes
II know for sure Cloud CDN and Cloud Load Balancer does and I was under the impression that the Cloud Run URL is just GCP-managed LB.
Doh wow you're right
CGitHub
Which Cloudflare product(s) does this pertain to? Wrangler core, Miniflare What version(s) of the tool(s) are you using? 3.19.0 [Wrangler] What version of Node are you using? 20.10.0 What operating...
SHey, so I want to use workers with nodejs package called GameDig. I want to call the worker service, and pass the location where should run. It is possible to give to the worker the region code where to execute?
CWorkers aren't nodejs, they run off the Chrome's Javascript engine V8, kind of like a new tab would, in their own isolates. There's some node compat and CF's own socket stuff, but you would need to majorly alter gamedig to use CF's Socket stuff, and it wouldn't work for anything that depends on UDP/CF only supports TCP. So minecraft would be possible, any steam game/using steam server query protocol wouldn't, and you can't tell the worker where to run. You could create a Durable Object and have it run in a few specific regions (<https://developers.cloudflare.com/durable-objects/reference/data-location/#provide-a-location-hint), but it's only a hint to a wide region and CF doesn't have DOs in South America/Africa atm
You can restrict a Durable Object to a jurisdiction, or provide a location hint.
SYeah, I would like to have udp games too.
SAnd I want to be as close to game servers the query.
SAnd I was thinking cloudflare workers would work because of the low latency overall.
Cudp sockets are somewhere in the plans, one day hopefully
Cby default it would be closest to the visitor/executor of the worker, not the server
Gheya guys. possible noob question as I'm super new to CF using it for a side project (https://vaella.glamboyosa.xyz) and environment variables and CF workers but.
say I have an environment variable in my dev.vars called database_id
and in the [vars] I reference database_id as database_id=$database_id
and also for environment.development
and it all works fine.
but how would I reference environment variables for production that way?
I am aware you could set up a GitHub action but I don't want to or need to so early. and I'd like to commit my wrangler.toml file with my sensitive data secure.
say I have an environment variable in my dev.vars called database_id
and in the [vars] I reference database_id as database_id=$database_id
and also for environment.development
and it all works fine.
but how would I reference environment variables for production that way?
I am aware you could set up a GitHub action but I don't want to or need to so early. and I'd like to commit my wrangler.toml file with my sensitive data secure.
Private Audio Rant Rooms
Gso kinda like on the Vercel dashboard where you can specify environment variables and it'll be read for prod deploys.
Glike I wanna be able to tell D1 to reference the database_id variable and it kinda point to the var in prod somehow when I use wrangler.
same for using wrangler deploy ...
I'd appreciate any guidance or examples (so j don't waste anyone's time if it's a bit too noob-ish!)
same for using wrangler deploy ...
I'd appreciate any guidance or examples (so j don't waste anyone's time if it's a bit too noob-ish!)
AWould a worker with service bindings to itself to boost the number of sub requests for logging purposes start interrupting the simultaneous open requests unless an event.waitUntil() and return is coded?
Dhuh, when my Worker does a
fetch
R1) Create
2) Create a projects dir in the root with desired project folders. Each folder will have whatever code you need
3) Adjust
4) Terminal
5) Adjust
No need to overcomplicate this. Use common libs in the root
package.json2) Create a projects dir in the root with desired project folders. Each folder will have whatever code you need
3) Adjust
scripts. In my case I use bun as why not. No need for pnpm workspace as this works the same if not better.4) Terminal
bun main-site install or bun install depends on what you want to do.5) Adjust
scripts in package.jsonbun main-site deploy or bun mail-worker devNo need to overcomplicate this. Use common libs in the root
package.json
KHey, is Workers a SaaS thing or a FaaS?
CFaaS
Jdoes anyone know a workaround for the following
B@Chaika i honestly would prefer to do this with r2 + cache. but im not sure how the cache thing works exactly? i get that cloudflare has some cache but how accessible is it to workers? and most importantly whats with the weird cache accessing syntax? i couldnt get it to work, i would get cache miss everytime
CSounds like you were trying to use Workers? With R2, you would be best off with just an R2 Custom Domain and a Cache rule to force it
Byeah i have a custom r2 domain, but when doing bindings is that domain used ?
CIf you use an R2 Custom Domain then you wouldn't pay for Worker Invocations and any cache hits are free
Cwhat do you mean "when doing bindings"?
Bi wasnt accessing r2 storage through fetch on my custom domain. i was accessing them through
wrangler.tomlThat wouldn't use the Custom domain or cache by default, you'd have to use the cache api yourself
Ci couldnt get it to work, i would get cache miss everytimeThe Cache API doesn't work/will always return miss in a bunch of environments, including dev
However, any Cache API operations in the Cloudflare Workers dashboard editor, Playground previews, and any *.workers.dev deployments will have no impact. For Workers fronted by Cloudflare Accesshttps://developers.cloudflare.com/workers/runtime-apis/cache/
, the Cache API is not currently available. Only Workers deployed to custom domains have access to functional cache operations.
Byeah i was doing the cache api manually but it wasnt working for some reason
Byeah my workers were also deployed with custom domains
Bi can show you my code if that will help
CSure
BBas you can see i was using same
cacheKey for both cache.match and cache.put. however it was always a missBim super confused on why
Request constructed from request.url has to be the cache key