C
S
R
H
R
K
definecontext.envglobal.envI did wonder this, but given they're defined on context.env which is bound to a request figured they must change dynamically?
context.envfetch(req, env, ctx)export default { async fetch(...) }Otherwise 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"If 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 deployIt 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.
KR
AsyncLocalStorageglobalThisenvBut 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.
KenvglobalThisAsyncLocalStorageAsyncLocalStoragenode: modules) then add the nodejs_compatpages dev then it'll use workerd
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
gitpages deployexport const onRequest = async (
requestContext: EventContext<any, any, any>
): Promise<Response> => {
globalThis.env = requestContext.env;
handleRequest(requestContext.request);
}node:pages devconsole.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.jspages deployimport { 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();