one worker shouldnt be reused across requests right?
one worker shouldnt be reused across requests right?
UA worker can and will be reused
HIt can be, though it is generally tied to a single browser call
UYou should never use global scope for request level data (really in any serverless env)
N
Hoh wait
HYeah, that
Njust tryna add some per-request id to my logs
Uyou can use something like async local storage that you run per request that contains the request id
Nlogs are sent from the server
Nand are unfortunately not async
Nunless im misunderstanding
UYou can still use ALS
Nas in the import from async_hooks ?
Uhttps://nodejs.org/api/async_context.html
Log with ID is actually the example on the docs for async local storage
Log with ID is actually the example on the docs for async local storage
Nthought that was node
Ucloudflare supports node apis ALS being one of them
Nnice
Nill try that then
Nthanks
Nim assuming something like this
NNnever used als
Ndont think it works unfortunately
Nyeah als.getStore() returns undefined. probably because the middleware doesnt actually run the code, just can alter response/request
Nyeah unfortunately cant find a way to do it. ill use middleware to log requests overall though
Nplease tell me node:async_hooks work on pages
Nit works in dev mode, with turbopack
Nbut i use webpack for prod
Nand that does
⨯ Error: Cannot find module 'node:async_hooks'Nalready done
Nin my config
JALS is heavily depended on in next.js and next-on-pages
N
Nsoo why am i having issues importing it lmaoo
Jwhat is it for?
Nwell my next-on-pages prooject
Ni use it for logging
Ni removed the ignore plugin and it works in webpack dev i think?
Nyeah
Nbut it fails to build
NNwhat am i missing
Nneeds this config to build:
i cant just remove
I'll see if it works in miniflare in a second
i cant just remove
node: from the import as i reuse the code for a page and a worker, and worker only works when the node: is specified lolI'll see if it works in miniflare in a second
Nhell yeah it works
RIs anybody able to advise on how to configure a Cloudflare Zone so that it doesn't do anything unexpected -- by "unexpected" I mean caches when not explicitly told to cache via Cache-Control headers from our Cloudflare Pages Functions, Workers or Origin servers.
Reading the docs, it seems the default CF cache rules are super complicated, so would love to tear them down so the origin is in complete control.
We have an enterprise account and I'm thinking we should enable "Origin Cache Control", although it's not clear to me exactly how to do this -- if we did enable Origin Cache Control, could there still be default configuration that might catch us out?
Reading the docs, it seems the default CF cache rules are super complicated, so would love to tear them down so the origin is in complete control.
We have an enterprise account and I'm thinking we should enable "Origin Cache Control", although it's not clear to me exactly how to do this -- if we did enable Origin Cache Control, could there still be default configuration that might catch us out?
HFor ultimate control, do you mean you want the origin to be able to control Cloudflare's caching of assets separately from browser caching?
RYeah, I want to be able to send either Cache-Control, CDN-Cache-Control or Cloudflare-CDN-Cache-Control headers with spec-compliant directives, depending on the desired behaviour at the origin
HI would assume this
[I]t indicates that Cloudflare should strictly respect Cache-Control directives received from the origin server. Free, Pro and Business customers have this feature enabled by default.Means that a Cache-Control family header should always win over any default values, assuming you don't have a rule telling it otherwise?
HIf not, I'll file an issue to get it clarified
RI guess there'd still be a risk that requests which don't return a Cache-Control header will get cached based on Cloudflare's default behaviour (file extension, status codes etc.)?
