Similar, but the intent is that the runtime would generally be defining those scopes rather than only ever being handled by a user-facing API. We have a bunch of discrete execution concepts which can be used as boundaries for these scopes such as a promise continuation or a callback. We could also probably extend the Function type with something like a func.bindToContext(value) which could be similar to having that function call run(...) internally.

My point is, we can have the nice DX of the set/get interface without too heavily exposing the scoping problem to users. Decoupling the scoping also makes it potentially reusable, which would be beneficial if we do decide to make separate types for the two around and through flows. It would simplify things for users if they can describes scopes with a single API and have both flow systems just make different decisions about how to link the scopes together in the graph.

Yes, unhandledrejection is one particular case where the desired context is always the flows-through context. You want to capture the context as it was when the rejection happened, even if it flows through a bunch of intermediate layers.

The difference between through and around flows is basically the same conceptually as subject and predicate. The through path gives you the subject of the failure so you can actually see what's going on. Whereas the around path gives you the predicate which is only describing what is being done with that subject, but that's not relevant in the case of a failure as it's what would have been done but will not be because of the failure.

This also matches that prior description of around flow being like parameter flow. It describes where execution is going and not so much where it came from, which is a bit counter-intuitive from the flow users have generally expected from AsyncLocalStorage where they want to know where something came from so they can acquired stored information about that originating execution.

And then the run function would essentially just be:

run(value, scope) {
  const prev = this.get()
  this.set(value)
  try {
    return scope()
  } finally {
    this.set(prev)
  }
}

so IIUC:

asyncVar.set("foo");

await (async () => {
	asyncVar.set("bar");
})();

console.log(asyncVar.get());  // bar

but

asyncVar.set("foo");

// No await!
(async () => {
	asyncVar.set("bar");
})();

console.log(asyncVar.get());  // foo

To distill things down to the essence of context management, all that is actually required to fully implement context flow is to capture three points:

• When a call schedules an async task the current context needs to be captured.
• When top-level or any nested continuations of async tasks would begin sync execution the context needs to be restored.
• And if context is not flowed completely into all paths then the end of sync execution may also be required as the next sync execution to begin may not apply a context swap before it runs if it is not something which context normally flows into. This point is why I think it's generally best to consider all execution as logically descending from the runtime starting and branch contexts off from that accordingly.

I think the flow-through pattern doesn't answer the similar problem of https://github.com/tc39/proposal-async-context/issues/90.

The originating context could be a stack of contexts and use inner-most context would discard all outer contexts. Each await creates resolution handler on a potentially rejected promise, use the inner-most context would lose the context when the rejection was handled multiple times.

let aGlobalPromise = asyncVar.run('global', () => {
  return Promise.reject()
})

async function someAsyncApi() {
  await asyncVar.run('async-inner', async () => {
    try {
      await aGlobalPromise
    } catch (e) {
      throw e
    }
  })
}

asyncVar.run("foo", async () => {
  await someAsyncApi()
});
asyncVar.run("bar", async () => {
  await someAsyncApi()
});

window.addEventListener("unhandledrejection", () => {
  console.log(asyncVar.get());  // 'foo' or 'bar' or 'global' or 'async-inner'?
});