Same as a normal request, `CF-Cache-Status` response header.
Same as a normal request,
CF-Cache-Status response header.
VWill this cache persist across multiple instances of this worker if the TTL is long enough?
KIt's no different to if you opened the URL in your browser - cache is a per-colo thing and assets can be evicted at any time.
KTTL is just a 'we won't keep it for longer' rather than 'we will keep it for this long' - maybe it gets evicted, maybe it doesn't.
VLike lets say in 1 instance of my worker, I call the same external resource 5 times. Ideally 1st time hits real, then the remaining 4 use the cached response. But then my worker gets re-run again 3 seconds later. Will the first fetch of this second instance use the cache of the first instance?
KMaybe?
KCache is per-colo and Workers are in every colo
VI'm thinking of setting a cache key of the incoming worker request so I can have unique per worker invocation, but same cache within
KAre you on an Enterprise plan?
Vno
KcacheKey is Enterprise only - if you're referring to fetch(..., { cf: { cacheKey: foo }});Voh
KThe Cache API allows fine grained control of reading and writing from the Cloudflare edge network cache.
VOk, for a bundled worker I know its 50ms (on paid) max run time. But in that run time, network waiting time for resources does not count, but I assume there is hidden limit there. Does anyone know what that is?
KThere is no hard limit for duration. However, after 30 seconds, there is a higher chance of eviction.
KKThere is no limit - just that if there is a need to restart the runtime, such as for an upgrade, 30 seconds is your grace period.
VI'm getting
CF-Cache-StatusDYNAMIC. Any way to force it to cache?KDepends - is the website you're fetching using Cloudflare themselves?
VAbout half my calls are the cloudflare api itself (for other products than workers), and the other half is not
HIs there any way we can have build time environment variables for workers? I know there is the runtime one but that won't work in my case because I need the env in one of the imported files which is done at the top before the worker script runs
HLooking for the equivalent of process.env.NODE_ENV in a CRA build, if that helps
KYou can use —define to replace globals at build time with Wrangler?
HI'm getting
Uncaught ReferenceError: ENV is not definedIf that's from trying to access
process.env--defineconsole.log(FOO)FOO"bar"I simply have
WORKER_ENV === 'stage'.tsIn my
wrangler.tomldefine = { WORKER_ENV = "stage" }So when I build the worker, it would say "stage" is not defined, because it's treating it as a variable name, which doesn't exist
H"stage" should be the variable value
BYou can always fallback to using bundler features.
K
K
Kit's also elided away since
if (false)in your scenario, if you want
FOO"bar"
HGot it. Thanks for investigating, that makes sense 
KThe whole thing could do with more documentation - it has like 2-3 lines of explanation in the commands section of the docs.
It's just https://esbuild.github.io/api/#define under the hood though
It's just https://esbuild.github.io/api/#define under the hood though
KSecrets are supposed to be managed with
wrangler secret put.dev.vars.gitignoreYes
