I did wonder this, but given they're defined on context.env which is bound to a request figured they must change dynamically?
context.env is a Pages/Functions wrapper over the fetch(req, env, ctx) that all Workers use. Your resulting built Worker will use export default { async fetch(...) }.
context.envfetch(req, env, ctx)export default { async fetch(...) }
KOtherwise I'd love to just have them on global.env so I don't have to pass them around to various modules all the time.
globalThis.reqId = "123" then other requests will be able to see and mutate that.KIf we were to update the env vars via the API in our build script, there'd be a race condition between deploys I expect, it'd need to be passed in as part of the wrangler deploy cmd I expect and not impact other deployments?
wrangler deploy has no way to do this, unfortunately. It is all done in the dashboard/API.KIt does seem a shame CF Pages doesn't let you define a deployment-level env var.... I guess it's because env vars are request-level in workers so perhaps not coupled to a deployment.
K
R
AsyncLocalStorage but felt it was a bit complex / overkill, just wanted to shove it on globalThisenvBut maybe bindings != env vars? (tbh I think I have a bit of a knowledge gap given my first usage of Workers is through Pages)
The bindings assigned to the Worker. As long as the environment has not changed, the same object (equal by identity) is passed to all requests.
KKKKKKWe were hesitant to add this on day 1 because we re-use isolates as a performance optimization wherever possible. This means that as we process one request with set of environment bindings, another request also start to be processed, potentially with a different set of environment bindings. In the typical Cloudflare Worker written in ESM format, this isn't an issue since the request and env come in together. However, if you were to access the environment from a global scope like Next.js does, there's a risk that the new set of environment bindings will override the previous set as that previous request is still processing.
To be clear, we do not share isolates across accounts (or even, across different Workers), so there's never as risk of your environment leaking across accounts or projects. Instead, if you updated your environment variables of your project as it served live traffic, we were concerned that potentially some requests would be 'polluted' with the newer set of environment variables as they were still being processed.
It turns out, that after some investigation, the way that Pages does deployments means that this won't happen anyway. It took us some time to confirm this, but we're now confident that there will be no accidental 'leakage' of environment bindings across deployments.
KenvglobalThisAsyncLocalStorage is as simple as above, I might try that as would be super handy to access the req too.KKAsyncLocalStorage (as well as other node:nodejs_compatpages devworkerd locally so you can just hammer that without having to worry about network latency/etc.RR
C
_worker.js file. I am really confused what could be causing it to try and push functions for a directory that doesn't contain any
IICCIIK
git in the folder of the direct upload, or passed by CLI to pages deploy
ICI
III
IIICI
<domain>.pages.dev that your website was assigned. Usually it's visible on the Pages project page.I
IIglobalThis.reqId = "123"wrangler deployAsyncLocalStorageAsyncLocalStorageAsyncLocalStorageexport const onRequest = async (
requestContext: EventContext<any, any, any>
): Promise<Response> => {
globalThis.env = requestContext.env;
handleRequest(requestContext.request);
}workerdconsole.log(">", requestContext.env.CF_PAGES);
console.log(">>", requestContext.env.CF_PAGES_COMMIT_SHA); // 🙌
console.log(">>>", requestContext.env.CF_PAGES_BRANCH); // 🙌
console.log(">>>>", requestContext.env.CF_PAGES_URL);// deployment
"deployment_trigger": {
"type": "ad_hoc",
"metadata": {
"branch": "feature/foo",
"commit_hash": "48e8ab8181e00008140866a28ffaa16e7a99161",
"commit_message": "Add foo",
"commit_dirty": false
}
},_worker.jsgit<domain>.pages.devimport { AsyncLocalStorage } from "node:async-hooks";
const asyncLocalStorage = new AsyncLocalStorage();
export const onRequest = async (
requestContext: EventContext<any, any, any>,
): Promise<Response> => {
return asyncLocalStorage.run(requestContext, () => {
return handleRequest();
});
};
function handleRequest() {
const requestContext = asyncLocalStorage.getStore();
const req = requestContext.request;
await requestContext.env.KV.put("foo", "bar");
}import getRequestContext from 'cloudflare:request-context';
const [ req, env, ctx ] = getRequestContext();