TC39 AsyncContext Integration
legendecas opened this issue · comments
What problem are you trying to solve?
TC39 stage 2 proposal AsyncContext adds new built-in APIs to propagate data through logically-connected sync/async code execution. It will need HTML/Web API integration to properly save and restore context data at the boundary of asynchronous call contexts, e.g. timers, event listeners, and observers.
- Define specification infrastructure
- ...
What solutions exist today?
The solution is not yet complete, submitting this proposal to open a space for discussion in HTML.
How would you solve it?
The issue tc39/proposal-async-context#82 has iterated on various integration points that are essential on the web platform.
The biggest thing we need to decide at the HTML level is, for each API which accepts callbacks, which AsyncContext.Snapshot should it be run in. Many of us are leaning towards "the snapshot where the callback-accepting API was first called".
Some Web APIs could benefit from passing an additional AsyncContext.Shapshot instance to the callback, e.g., it might be useful for window.onerror to have access to the current snapshot when the exception was thrown--this could be an attribute attached to the Event, or the Error/DOMException, for example.