Using an `AsyncLocalStorage` snapshot across requests

[vicb]

Repro: https://github.com/vicb/als-snapshot

When an AsyncLocalStorage.snapshot() is used in a different request as the one it was created in, the following error is generated:

[wrangler:inf] GET / 302 Found (6ms)
using snapshot
[wrangler:err] Error: Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloudflare Workers which allows us to improve overall performance. (I/O type: SpanParent)
    at Object.apply ([...]/strip-cf-connecting-ip-header.js:9:18)
    at null.<anonymous> ([...]/src/index.ts:31:39)
    at Object.fetch ([...]/src/index.ts:31:12)
    at fetchDispatcher ([...]/middleware-loader.entry.ts:54:17)

The issue happens when using composable cache in Next with the cloudflare adapter, see opennextjs/opennextjs-cloudflare#666 - Thanks @conico974 for figuring the issue out and submitting a patch.

I discussed this offline with @jasnell and he asked me to create the issue.

Not sure if this is something that we can fix or working as intended.

[jasnell]

The Key issue here, I believe, is that the async context is capturing a span context that is specific to the original request, so when we reenter that context from a different request and the internals grab that span context, things go boom. I do think it's possible to fix but we need to carefully consider how to avoid other potential issues.

I wouldn't necessarily label this a bug because it's actually working as intended, it's just surprising behavior that users won't expect and really can't do anything about, so addressing this is a matter of improving DX as opposed to fixing a bug.

[jasnell]

Not yet sure exactly what change to make here but here's the simplest reproduction that shows the issue...

import { AsyncLocalStorage } from 'node:async_hooks';

let snapshot;
const als = new AsyncLocalStorage();

export default {
  async fetch(req, env) {

    // AbortController and AbortSignal objects are specific to the IoContext
    als.run(new AbortController(), () => {
      snapshot ??= AsyncLocalStorage.snapshot();
    });

    snapshot(() => {
      console.log(als.getStore());
    });

    return new Response("Hello World\n");
  }
};

[jasnell]

We've "fixed" this by making ALS snapshots specific to the individual request in which they were created. It means the error that you get in this case is more specific to the issue rather than the cryptic I/O error.