I think that's tricky due to races - for example, the exact ordering of a promise resolving vs. the promise.then call would make one or the other context more recent. But I think we probably want to run in the same context (resolution vs registration) regardless of the order.

this smells like zalgo -- it depends on how the handlers are called

Because the scoped mutation is disposed in the FunctionStatementList evaluation of the function, and the outer promise is resolved in the AsyncFunctionBody execution after StatementList is evaluated

it's a little pedantic, but if you have something like

const p = v.run(1, () => Promise.resolve());
await p;
// p is now fully resolved
v.run(2, p.then(() => console.log(v.get())));

Then "the most specific (i.e. causally recent) relevant context" would presumably be the 2, since the callback was registered after the promise resolved. Without the await, it would be 1.

it's a little pedantic, but if you have something like

const p = v.run(1, () => Promise.resolve());
await p;
// p is now fully resolved
v.run(2, p.then(() => console.log(v.get())));

Then "the most specific (i.e. causally recent) relevant context" would presumably be the 2, since the callback was registered after the promise resolved. Without the await, it would be 1.

This is why other languages like .NET went for just doing set/get and persisting until the context would change.

Is there some nuance here between persisting until the context would change vs. persisting until the end of a scope? Does the former somehow allow escaping a changed value out of a scope where the latter doesn't? I'm still trying to wrap my mind around how you can actually observe a changed value in a child scope if the change gets reverted before you resume.

In flow-through model that should always be 1, as that is what was set when the resolve happened. We don't much care about where a continuation is attached.

Is there some nuance here between persisting until the context would change vs. persisting until the end of a scope? Does the former somehow allow escaping a changed value out of a scope where the latter doesn't? I'm still trying to wrap my mind around how you can actually observe a changed value in a child scope if the change gets reverted before you resume.

Right, but I'm imagining a world where await is flow-around, but then restores the resolution context, since that would still allow accessing all the flow-through causes as needed.

And probably would have terrible performance for APMs which would need to be doing that basically always.

yeah I have been assuming that .then would always use the registration context, and that we were only talking about web APIs.

Steve Hicks: Thoughts on this?

I think it's a sticky situation. The default is less relevant - even if flow-around is the user-facing default, I don't see why it couldn't be implemented internally as the option that adds additional processing on top of the flow-through codepath. What's not clear to me is whether flow-through is viable at all, even as an option. My understanding is that SES would block it outright, so even if we want it we can't really have it.

Assuming we have flow-around for await, there will always be fundamental disagreement between the context propagation of callbacks and async-await. Promises has to choose one or the other. Registration aligns it with async-await, resolution aligns it with callbacks. It's not clear to me that one is fundamentally better than the other, but the latter opens up a possibility to access semantics that are impossible with the former.

But IIUC the concern was less about passing a value directly and more about causing an observable side effect in a variable (by controlling the global snapshotting) without actually having access to that variable.

I expressed this in the doc and slides I shared previously, but to repeat that: there are many layers of execution rearrangement occurring in JS. The base level of the microtask scheduler is fairly obvious to bind around, but as you raise further and further out into layers closer to user code it becomes less and less obvious what the "correct" path is when flowing around.

Not accidentally escaping. Intentionally escaping.

So you can get the same behaviour as flow-around if you use the variables carefully.

Something like await bindPromise(promise) which would just capture context at the point bindPromise(...) is called and restore it when the given promise calls its continuation let you trivially restore around flow.