AsyncContext is a stage 2 (hopefully soon stage 2.7) TC39 proposal that provides a way to associate state with an asynchronous flow of control in JS, such that you could propagate non-local values through awaits, or across tasks scheduled in the event loop. Since task attribution needs to propagate the task attribution ID across awaits and across task scheduling, it could be built on top of AsyncContext.
The details of how AsyncContext should propagate across tasks scheduled by web APIs, as well as other details in terms of integration with web specs, are outlined in a document in tc39/proposal-async-context#100. This is a proposal and not yet fully settled, but we think this is the behavior AsyncContext should have with web APIs.
It might be that task attribution does not in fact fit very well with the context propagation semantics for web APIs that we are proposing for AsyncContext. In particular, our proposal is that event listeners should be called with the context in which addEventListener (or e.g. setting onclick) was called. This does not match task attribution, where by default event listeners would create a task scope with no parent.
I think it would be beneficial, implementation-wise if not spec-wise, if we could find a way to make task attribution work in terms of AsyncContext. This could be done by essentially doing the equivalent of AsyncContext.Variable.prototype.run on every task where their semantics differ, but it might have an effect on performance. And since issue 2 in the spec suggests defining some registration semantics by default, we should consider which semantics are strictly needed for task attribution, and see how to make them work with AsyncContext.
AsyncContext is a stage 2 (hopefully soon stage 2.7) TC39 proposal that provides a way to associate state with an asynchronous flow of control in JS, such that you could propagate non-local values through
awaits, or across tasks scheduled in the event loop. Since task attribution needs to propagate the task attribution ID acrossawaits and across task scheduling, it could be built on top of AsyncContext.The details of how AsyncContext should propagate across tasks scheduled by web APIs, as well as other details in terms of integration with web specs, are outlined in a document in tc39/proposal-async-context#100. This is a proposal and not yet fully settled, but we think this is the behavior AsyncContext should have with web APIs.
It might be that task attribution does not in fact fit very well with the context propagation semantics for web APIs that we are proposing for AsyncContext. In particular, our proposal is that event listeners should be called with the context in which
addEventListener(or e.g. settingonclick) was called. This does not match task attribution, where by default event listeners would create a task scope with no parent.I think it would be beneficial, implementation-wise if not spec-wise, if we could find a way to make task attribution work in terms of AsyncContext. This could be done by essentially doing the equivalent of
AsyncContext.Variable.prototype.runon every task where their semantics differ, but it might have an effect on performance. And since issue 2 in the spec suggests defining some registration semantics by default, we should consider which semantics are strictly needed for task attribution, and see how to make them work with AsyncContext.