Oh, interesting. Presumably good old, synchronous, browser-style `globalObject.localStorage` wouldn'

Oh, interesting. Presumably good old, synchronous, browser-style

globalObject.localStorage

globalObject.localStorage

globalObject.localStorage

globalObject.localStorage wouldn't work? If so, using AsyncLocalStorage, am I right that it would look something like this, to store a global property for later reading downstream?
Upstream file:

import { AsyncLocalStorage } from 'node:async_hooks';
const fooStore = new AsyncLocalStorage();
fooStore.run('bar'); //<-- running in some async middleware

import { AsyncLocalStorage } from 'node:async_hooks';
const fooStore = new AsyncLocalStorage();
fooStore.run('bar'); //<-- running in some async middleware

import { AsyncLocalStorage } from 'node:async_hooks';
const fooStore = new AsyncLocalStorage();
fooStore.run('bar'); //<-- running in some async middleware

import { AsyncLocalStorage } from 'node:async_hooks';
const fooStore = new AsyncLocalStorage();
fooStore.run('bar'); //<-- running in some async middleware

Downstream file:

import { AsyncLocalStorage } from 'node:async_hooks';
const fooStore = new AsyncLocalStorage();
const fooVal = fooStore.getStore(); //"bar"

import { AsyncLocalStorage } from 'node:async_hooks';
const fooStore = new AsyncLocalStorage();
const fooVal = fooStore.getStore(); //"bar"

import { AsyncLocalStorage } from 'node:async_hooks';
const fooStore = new AsyncLocalStorage();
const fooVal = fooStore.getStore(); //"bar"

import { AsyncLocalStorage } from 'node:async_hooks';
const fooStore = new AsyncLocalStorage();
const fooVal = fooStore.getStore(); //"bar"

JJadugar_Jaggu hey guys is anyone familiar with this issue? I am facing it right after automati...

Chaika•3/4/24, 4:46 PM

Thanks for reporting. I would watch this incident for further updates on the issue, and try again when it is resolved:
https://www.cloudflarestatus.com/incidents/3q7sg3tpp7qv

Issues changing CPU Limit for Cloudflare Workers and Pages

MMitya Oh, interesting. Presumably good old, synchronous, browser-style `globalObject.l...

kian•3/4/24, 4:46 PM

import { AsyncLocalStorage } from "node:async_hooks";

const asyncLocalStorage = new AsyncLocalStorage();

async function doStuff() {
  const { req, env, ctx } = asyncLocalStorage.getStore();

  const obj = await env.KV.get("foo");

  // ...
}

export default {
  async fetch(req, env, ctx) {
    return asyncLocalStorage.run({ req, env, ctx }, async () => {
      await doStuff();

      return new Response("Hello World!");
    });
  },
};

import { AsyncLocalStorage } from "node:async_hooks";

const asyncLocalStorage = new AsyncLocalStorage();

async function doStuff() {
  const { req, env, ctx } = asyncLocalStorage.getStore();

  const obj = await env.KV.get("foo");

  // ...
}

export default {
  async fetch(req, env, ctx) {
    return asyncLocalStorage.run({ req, env, ctx }, async () => {
      await doStuff();

      return new Response("Hello World!");
    });
  },
};

kian•3/4/24, 4:47 PM

runrun takes the object you want to store, and then a callback

MityaOP•3/4/24, 4:49 PM

Thanks @kian . So I was nearly there but just need to pass an object? And presumably the callback is optional if all I'm doing is writing to the store for future use, rather than, as per the docs example, sending a response once write is complete?

kian•3/4/24, 4:49 PM

Doesn't necessarily have to be an object

kian•3/4/24, 4:49 PM

Can be a string, number, array, etc

MityaOP•3/4/24, 4:50 PM

Yeah... so my original effort would work? (I passed just a string value there, not an object.) But is the general flow correct? Appreciate the help.

kian•3/4/24, 4:50 PM

runrun requires the callback

kian•3/4/24, 4:50 PM

The idea is that it runs that function async within a 'context'

kian•3/4/24, 4:50 PM

and the store for that context is what you passed as the first arg

MityaOP•3/4/24, 4:51 PM

Ah... then I'm struggling a little. You're saying mystore.run({foo: bar})mystore.run({foo: bar}) is insufficient to write to the storage? If so, what would any callback I passed actually "do", if all I want to do is write for later reading?

kian•3/4/24, 4:58 PM

The storage is only available within the function passed to runrun

kian•3/4/24, 4:59 PM

i.e in my case, I put everything inside the function I pass to runrun and return my Response there

kian•3/4/24, 4:59 PM

Everything else can now do asyncLocalStorage.getStore();asyncLocalStorage.getStore(); to access req, env, ctx

MityaOP•3/4/24, 5:00 PM

OK, that makes sense. But does this mean that downstream files/functions in other files will not be able to access the storage value because they're not running in run()run()'s callback?

Say file A (middleware) wants to write a value to storage. That middleware then hands over to a controller (file B), which then calls a helper function in file C. Is it possible files B/C to access the storage value written by file A?

MityaOP•3/4/24, 5:01 PM

Sorry - this is all new to me and I'm having a little difficulty. I do appreciate the help.

kian•3/4/24, 5:03 PM

Do you have a minimal example of the layout/middleware? It might be easier if I adapt that to use AsyncLocalStorage and you can see how it works.

MityaOP•3/4/24, 5:05 PM

Sure. I'm using itty-router. So:

import fooApi from '../controllers/foo'
router.post('/foo/bar', async req => {
  const resp = fooApi.bar(); //e.g. "hello world"
  return resp;
})

import fooApi from '../controllers/foo'
router.post('/foo/bar', async req => {
  const resp = fooApi.bar(); //e.g. "hello world"
  return resp;
})

I'd like to be able to set a local storage value in that middleware, but have my function at fooApi.bar()fooApi.bar() (in controllers/foo.jscontrollers/foo.js) be able to access that stored value.

MityaOP•3/4/24, 5:06 PM

controllers/foocontrollers/foo:

export default {
  bar: () => {
    //how to access local storage value in here? I'm not in the middleware's storage.run() callback at this point...
  }
};

export default {
  bar: () => {
    //how to access local storage value in here? I'm not in the middleware's storage.run() callback at this point...
  }
};

kian•3/4/24, 5:15 PM

export const als = new AsyncLocalStorage();

router.get("/", async () => {
    return als.run("foo", async () => {
        const resp = foo.bar();
        return new Response(resp);
    });
});

export const als = new AsyncLocalStorage();

router.get("/", async () => {
    return als.run("foo", async () => {
        const resp = foo.bar();
        return new Response(resp);
    });
});

import { als } from ".";

export default {
    bar: () => {
        return als.getStore();
    },
};

import { als } from ".";

export default {
    bar: () => {
        return als.getStore();
    },
};

kian•3/4/24, 5:15 PM

Admittedly it's not ideal with multiple modules as you have to pass around the top-level alsals

Kkian ```js export const als = new AsyncLocalStorage(); router.get("/", async () => {...

Hello, I’m Allie!•3/4/24, 5:16 PM

I forget, can’t you shim the storage onto GlobalScope?

kian•3/4/24, 5:17 PM

I wonder if globalThis.als = new AsyncLocalStorageglobalThis.als = new AsyncLocalStorage would work

kian•3/4/24, 5:17 PM

:blobcatthonking:

Kkian I wonder if `globalThis.als = new AsyncLocalStorage` would work

Hello, I’m Allie!•3/4/24, 5:17 PM

https://tenor.com/view/great-minds-think-like-smile-smart-gif-14683105

Tenor

MityaOP•3/4/24, 5:17 PM

That would be great if so (but if it does, couldn't I just hook my data onto globalThisglobalThis in the first place and bypass ALS?)

MMitya That would be great if so (but if it does, couldn't I just hook my data onto `gl...

Hello, I’m Allie!•3/4/24, 5:18 PM

You would have no guarantee that the data isn’t changed from one request to another

Hello, I’m Allie!•3/4/24, 5:18 PM

So you might also mix requests from multiple clients

MityaOP•3/4/24, 5:18 PM

Ahh, right, so that would be back to my original problem

MityaOP•3/4/24, 5:19 PM

Final question:

import { als } from ".";

import { als } from ".";

...in my controller. Could you kindly explain how that works? That seems to be importing a variable from the scope that called my controller function. Is that right? I've never seen that before - I've only ever seen importimport reference modules/files.

kian•3/4/24, 5:20 PM

globalThis.als = new AsyncLocalStorage();globalThis.als = new AsyncLocalStorage(); seems to work too

kian•3/4/24, 5:21 PM

kian•3/4/24, 5:21 PM

kian•3/4/24, 5:21 PM

(notice how the d7d6d2f4d7d6d2f4 isn't overwritten by 987f4e92987f4e92 like it would be if you just stored them on globalThisglobalThis)

MityaOP•3/4/24, 5:23 PM

Riiiiiiiiiight... this is where my behind-the-scenes Node knowledge is lacking.

So if hooking things directly onto globalThisglobalThis runs the risk of multi-request leakage, how come I avoid that problem by hooking the (same) ALS onto globalThisglobalThis? How does that avoid the same issue, since each request will be running that code (making a store, hooking the same property name onto it?) In other words, what guarantees that request 1 hooking foo=1foo=1 and request 2 hooking foo=2foo=2 will be preserved within the scope of their respective requests, using ALS?

kian•3/4/24, 5:24 PM

kian•3/4/24, 5:24 PM

The "why" is that it's implemented by the runtime & tracks the async context for you - that's all done in C++

magic

kian•3/4/24, 5:26 PM

https://github.com/cloudflare/workerd/blob/bd06b08cc729b136f4dc22e39e47b5c8ef7ecbd1/src/workerd/jsg/README.md?plain=1#L1529-L1599

MityaOP•3/4/24, 5:26 PM

Riiiight, thank you. So to summarise:
- globalThis.fooglobalThis.foo set in one file and read in another file risks mutation/leakage from other requests
- globalThis.alsglobalThis.als, where alsals is a store with {foo: <something>}{foo: <something>} set on it, avoids that problem

kian•3/4/24, 5:30 PM

Yep.

kian•3/4/24, 5:30 PM

https://www.youtube.com/watch?v=ukefzxZ_G9U is by James Snell, who is a NodeJS maintainer and also a Cloudflare employee who was involved in implementing AsyncLocalStorage into Workers too

YouTubeThis Dot Media

Async Context Tracking in Node with Async Local Storage API ft. Jam...

In this JS Drop, James Snell goes over how Async Local Storage API works. He goes over the drawbacks of cascading functions for attaching information the traditional way, and why using Async Local Storage API (now stable) may be a more efficient use with Async Context Tracking.

Follow James Snell on Twitter: https://twitter.com/jasnell

JS Drop...

kian•3/4/24, 5:31 PM

It might help explain how it works

MityaOP•3/4/24, 5:33 PM

Thanks, I'll give that a go. Coming from PHP, it's weird getting your head around the idea that things are not all isolated to the request only! Just needs a change in mindset. Anyway I really appreciate your guys' help and patience. You're a credit to CF. Have a good evening.

kian•3/4/24, 5:37 PM

In Workers, the only thing that's isolated is within your fetchfetch handler which is it's own "asynchronous duration" - it's an async function, basically called by the runtime.

When you call als.run(..., async () => { ... });als.run(..., async () => { ... }); inside your fetchfetch handler, alsals keeps track of what context it was called in (this specific call of the fetchfetch handler).

When your other modules are calling als.getStore()als.getStore(), those modules were called within that runrun callback - it's tied to that invocation of the fetchfetch handler.

If you tried calling als.getStore()als.getStore() within the fetchfetch handler but outside of the runrun callback, it'd be

undefined

undefined

. runrun stores what you pass to it in a context that's only available to the callback, and other calls to runrun by other requests doesn't mutate our store since alsals knows that is a separate invocation of the fetchfetch handler.

kian•3/4/24, 5:40 PM

https://github.com/cloudflare/workerd/blob/bd06b08cc729b136f4dc22e39e47b5c8ef7ecbd1/src/workerd/jsg/async-context.h#L15-L66 talks a bit about the technical details behind it.

Angel Luis•3/4/24, 7:33 PM

Hi, I join here because I'm very upset with Workers KV. After 2 hours trying everything, I've noticed that KV in local development doesn't fetch the KVs unless you create them inside the local project via local Worker. It doesn't appear in any documentation, and it has no sense. You creates a namespace with Wrangler then it's created in the Dashboard, and also is accesible in your local project. Okay. Now, you creates a new key-value pair which is accesible in the Dashboard. You want to access it from your local project with an env.whatever.get(), and in my case, I spend almost 2 hours thinking that I've some kind of environment problem in my project, because you don't get any pair. Why? Because it only works in production. If I want to use the pairs created using Wrangler or the Dashboard I can't! I've to create via Worker the same pairs to have the same key pairs. At least, this is the only way that I have been able to deduce. But in the documentation, there is nothing regarding this

AAngel Luis Hi, I join here because I'm very upset with Workers KV. After 2 hours trying eve...

Unsmart•3/4/24, 7:35 PM

This is documented here: https://developers.cloudflare.com/workers/wrangler/configuration/#kv-namespaces and here https://developers.cloudflare.com/workers/observability/local-development-and-testing

To use remote resources you run wrangler dev --remotewrangler dev --remote

UUnsmart This is documented here: <https://developers.cloudflare.com/workers/wrangler/con...

Angel Luis•3/4/24, 7:41 PM

wow I didn't find that, in my opinion the paragraph/note:

"When using Wrangler in the default local development mode, files will be written to local storage instead of the preview or production namespace."

Should be at least in the "Get started" guide. The guide introduce both Wrangler/Worker methods as same, but the behaviour is completely different. I understand the point that if you're a pro with Workers, the local development behaviour can be pretty clear, but until this moment I didn't need to differenciate the environments, and for someone new is very confusing to don't have that info in the starter guide

(thanks for sharing)

Unsmart•3/4/24, 7:43 PM

It is also documented on the get started with kv page https://developers.cloudflare.com/kv/get-started/#5-develop-locally-with-wrangler

Unsmart•3/4/24, 7:43 PM

You can always open github issues if you think documentation isnt clear and should be updated though https://github.com/cloudflare/cloudflare-docs/issues/new/choose

Oh, interesting. Presumably good old, synchronous, browser-style `globalObject.localStorage` wouldn'

Similar Threads

Similar Threads

Similar Threads