• https://source.chromium.org/search?q=continuation_preserved_embedder_data%20-filepath:%5Eout%2F&ss=chromium%2Fchromium%2Fsrc
• Preserved on jobs: https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/promise-misc.tq;l=75-90;drc=39c3a97e848a7ecd1fa95e738771cc61d6d72552
• Restored on run: https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/builtins-microtask-queue-gen.cc;l=238-245?q=continuation_preserved_embedder_data%20-filepath:%5Eout%2F&ss=chromium%2Fchromium%2Fsrc

Only code with direct access to AsyncContext instances can modify the value, and only for code execution nested inside a new context.run().

• https://github.com/endojs/endo/blob/markm-fluid-scopes/packages/eventual-send/src/async-contexts/7-fluid-passing-style-transform.md
• https://github.com/endojs/endo/blob/markm-fluid-scopes/packages/eventual-send/src/async-contexts/7-fluid-passing-style.js

als.run(123, () => queueMicrotask(() => console.log(als.getStore())));

Looks like that's actually possible with SetPromiseRejectCallback:

• https://source.chromium.org/chromium/chromium/src/+/main:v8/src/api/api.cc;l=9491-9495;drc=c53c026e6ee5083d71e1cd63607ecbae0c641678
• called by https://source.chromium.org/chromium/chromium/src/+/main:v8/src/runtime/runtime-promise.cc

Yoav told me that, for web APIs, he added extra logic to save and restore the right thing when queueing [macro]tasks

Justin Ridgewell in v8 or somewhere else?

          jsg::AsyncContextFrame::Scope scope(js, jsg::AsyncContextFrame::current(js));
          auto ev = jsg::alloc<PromiseRejectionEvent>(event, kj::mv(promise), kj::mv(value));
          dispatchEventImpl(js, kj::mv(ev));

It's a bit obscure here but...

jsg::AsyncContextFrame::current() is a wrapper around code that grabs the current stored continuation data from v8::Context

In JavaScript...

const { AsyncLocalStorage } = async_hooks;

const als = new AsyncLocalStorage();

addEventListener('unhandledrejection', (event) => {
  // Here we are making sure that the async context properly travels along with
  // unhandled rejections.
  if (event.reason === 'boom' && als.getStore() !== 123) {
    throw new Error("Incorrect async store value");
  }
  if (event.reason === 'boom2' && als.getStore() !== 'ABC') {
    throw new Error("Incorrect async store value");
  }
});

addEventListener('rejectionhandled', (event) => {
  if (als.getStore() !== 'ABC') {
    throw new Error("Incorrect async store value");
  }
});

export default {
  async fetch(request) {
    // The async context is captured when on(...) is called to register
    // handlers.
    als.run(123, () => {
      Promise.reject("boom");
    });

    const p = als.run('ABC', () => {
      return Promise.reject("boom2");
    });

    await scheduler.wait(1);

    p.catch(() => {});

    return new Response("ok");
  }
}

new Promise((_, rej) => rej(1));
new Promise(res => res(Promise.reject(1)));
// technically equivalent to the previous one
Promise.resolve().then(() => Promise.reject(1));

For the following case, what would you expect the als.getStore() value to be printed..

addEventListener('unhandledrejection', () =>{
  console.log(als.getStore());
})

let reject;
const p2 = als.run(123, () => new Promise((a,b) => reject = b));
als.run(321, () => reject());

https://github.com/nodejs/node/issues/46262

Nit: "promise is resolved" should say "promise is settled"

Specifically, I think by default, we should capture the context on settle not kInit. So the answer by default should be 321. If you want 123, then use wrap around reject as suggested by Justin. Or, if we are using a mechanism like Node.js' AsyncResource, we can do something like:

class Foo extends AsyncResource {
  constructor() {
    this.deferredPromise = createDeferredPromise();
  }

  resolve() { this.runInAsyncScope(() => this.deferredPromise.resolve()) }
  reject() { this.runInAsyncScope(() => this.deferredPromise.reject()) }
}