So, here's a question. fetch has the Response object. This can be created using a ReadableStream object, which uses a number of internal promises to manage state. In workerd, we have a method that handles received requests and can return a Response object specifying the response to an http request. So, imagine a case like:

const als = new AsyncLocalStorage(); // or AsyncContext
export default {
  async fetch(req) {
    const readable = als.run('abc', () => new ReadableStream({
      pull(c) {
        c.error(new Error(`boom ${als.getStore()}`));
      }
    }));
    return als.run(123, () => new Response(readable));
  }
}

The actual pipe from the readable happens by the code that calls the fetch function handler here, which is running in the root async context where als store will be undefined.

What value would you expect als.getStore() to return when the error is constructed?

  async fetch(req) {
    const readable = als.run('abc', () => new ReadableStream({
      pull: AsyncContext.wrap((c) => {
        c.error(new Error(`boom ${als.getStore()}`));
      }),
    }));
    return als.run(123, () => new Response(readable));
  }
}

Here's another example:

const als = new AsyncLocalStorage();

const readable = als.run(123, () => new ReadableStream({
  pull(c) {
    c.error(`boom ${als.getStore()}`);
  }
}, { highWaterMark: 0 }));
const response = als.run('abc', () => new Response(readable));
const reader = als.run('xyz', () => response.body);
const read1 = als.run(321, () => reader.read());
const read2 = als.run(567, () => reader.read());
await Promise.all([
  als.run('???', async () => await read1),
  als.run('!!!', async () => await read2)
]);

we can break this down to a few specific questions:

1. Because the various "algorithms" associated with a stream are considered part of its internal implementation (e.g. start, pull, close), should those always be executed in the async context frame in which the stream itself was created or should they propagate the context that triggered the algorithm to be called

2. If a read promise rejects and is unhandled, should the unhandledrejection event be called in the async context in which the read promise was rejected (which is likely different than the context that scheduled the read), or the async context that was current when the read was scheduled

Keeping in mind also that people can do silly things like..

let controller;
const readable = als.run(123, () => new ReadableStream({
  start(c) { controller = c; }
}));
const read = als.run('abc', () => readable.getReader().read());
als.run(321, () => controller.error('boom'));