I think that maybe the only cases where events should be registration time are the ones where there isn't any possible JS origin for the event

What is the example code? What is the indicated issue URL? We’d previosuly discussed why we don’t have an enterWith API because of cases like this, it needs to properly restore the context after the execution of the inner async function pauses its await. Part of the reason we discussed using declarations with modifications to await keyword to restore the previous context at the suspend point.

What issue? There were like 400 messages in this channel over the last week.

So it’s the case where doSomething doesn’t create a parent span for its children? And we have to infer order of sibilngs when two doSomething calls are interleaved. Is this not just user error?

I spoke with the tracing experts I'm working with and they strongly prefer "flow around" semantics over "flow through" await (with a caveat that their primary experience is in other languages). In particular, the concern is that the ability to do an unbounded set() isn't a good situation. Further, they weren't at all concerned with the visibility issues from pruning off subtasks by binding around them, for two reasons: (1) exact follows-from relationships are primarily relevant for critical path analysis, which already has numerous other issues making it intractable, and (2) we can get a reasonable enough picture with the mutable trace objects referenced in a "lexically scoped" async store (i.e. what's currently proposed here). The rough structure we use (IIUC) is that the async-local variables are trivially cheap span IDs and the global store is a log of events that includes those IDs. When a span begins/ends, it gets a new ID the start/end times and parents are appended to the log (along with any additional metadata). The graph can then be reconstructed later from that log.

I agree completely with Justin's assessment of the doSomething() example - it wouldn't be an issue if doSomething were properly instrumented. If you branch into two parallel subtasks without making a child span, you're asking for a bad time.

I was kinda thinking out loud, and the fact that zone.js was probably the main reason why we were going with registration-time by default is something I noticed just now

Node.js defaults to running everything in the scope where the emit happened, but EventEmitterAsyncResource exists to chose register time for an entire event emitter as-needed.

How about an option on dispatchEvent to fire the event with the registration context, rather than the current one?

This is exactly what I'm talking about. You seem to be explicitly aiming for binding around awaits, cutting off the branched execution merging back. This is explicitly what most users have told me they don't want. The code coming out of that await is a continuation, so it's essentially the same as if the remaining code was passed into that call as a callback, which does propagate context through. The fact that promises and async/await will not flow context through to continuations is extremely confusing to literally every user I've talked to about this. The whole point of context management to everyone I have talked to is to be able to set a value at some point in a branch of async execution and to be able to retrieve that same value anywhere in logically continuing execution, which any merge point like awaits, promise continuations, or callbacks all are.

The fact we are specifying a behaviour which seemingly no one outside of this group is asking for is very strange to me.

I think that maybe the only cases where events should be registration time are the ones where there isn't any possible JS origin for the event

do you ever use that to monkeypatch built-ins? is it better than just monkeypatching the EventEmitter methods on the object itself?

do you ever use that to monkeypatch built-ins? is it better than just monkeypatching the EventEmitter methods on the object itself?

Honestly I find the flow-through behavior to be much more confusing. I suspect this has to do with my starting point. I (and I think others here) come from a perspective where this is an implicit version of what golang does explicitly with their Context object. When you pass a Context into a subtask, that task is free to make its own child Contexts with different mappings, but because Context is itself immutable, there's no way for those changes to be visible to the caller. So from the point of view of seeing this as just a bag for passing implicit parameters, there's no expectation that a callee could change one for a caller (unless the passed object is itself mutable).

If you are instead coming from a perspective where the purpose of this is to provide a mechanism to track execution flow, then I suspect the surprise goes in the opposite direction. So the question is (1) which of these is AsyncContext intended to be, and (2) is there any reasonable way for it to do both? Is "context" even the right concept for tracking execution flow, or is there something else that could do it more naturally?

Cancellation is an example of a use case where bind-around is what we want. Suppose we have a "globally well-known" abort: AsyncContext.Variable<AbortSignal> for the current task. Well-behaved jobs can inspect it and throwIfAborted, pass it along to things like fetch (or even have fetch use it implicitly), etc. Suppose you want to do something that can be cancelled independently of the upstream abort - you can const c = new AbortController() and then abort.run(AbortSignal.any(abort.get(), c.signal), ...), and the child task can be cancelled by either the parent or the new child controller. Now imagine you've just programmatically added 5 cards to a view, which each need to fetch data and render themselves. You might kick off 5 fetches, each with its own child signal. If the user dismisses one of those cards while it was still loading, we can abort that one child controller individually. But it would clearly be a mistake to end up with one of those child signals as the current signal after await Promise.all(childCards).

I think you’re misinterpreting my statement. We can have flow-through semantics without enterWith. enterWith is a foot-gun that exposes an unfixable memory leak, and I specifically opose that. I will not accept a design that has an unparied enter/exit.

Cancellation is an example of a use case where bind-around is what we want. Suppose we have a "globally well-known" abort: AsyncContext.Variable<AbortSignal> for the current task. Well-behaved jobs can inspect it and throwIfAborted, pass it along to things like fetch (or even have fetch use it implicitly), etc. Suppose you want to do something that can be cancelled independently of the upstream abort - you can const c = new AbortController() and then abort.run(AbortSignal.any(abort.get(), c.signal), ...), and the child task can be cancelled by either the parent or the new child controller. Now imagine you've just programmatically added 5 cards to a view, which each need to fetch data and render themselves. You might kick off 5 fetches, each with its own child signal. If the user dismisses one of those cards while it was still loading, we can abort that one child controller individually. But it would clearly be a mistake to end up with one of those child signals as the current signal after await Promise.all(childCards).

It's not an unpaired enter/exit though. The enter/exit is just left up to the runtime. so a microtask boundary, or the execution scope of the top-level script or module. There's still a clearly defined scope you can use, and this is what literally every other language does, it's just under full control of the runtime to define them rather than leaving it up to the user to define their own custom boundaries, which are arguably more complex to reason about because the runtime can't do things like having the optimizer rearrange execution around these boundaries without breaking the context guarantees.

The set/get style is much better in terms of closure reduction, more flexible and better suited to async/await flows, and equally as safe as the store.run(...) form.