Repository navigation
TC39 AsyncContext #1187
Description
Specification title
AsyncContext
Specification or proposal URL (if available)
https://github.com/tc39/proposal-async-context
Explainer URL (if available)
https://github.com/tc39/proposal-async-context/blob/master/WEB-INTEGRATION.md
Proposal author(s)
@andreubotella @legendecas @jridgewell
MDN URL
No response
Caniuse.com URL
No response
Bugzilla URL
No response
Mozillians who can provide input
WebKit standards-position
WebKit/standards-positions#569
Other information
The TC39 AsyncContext proposal provides a language built-in mechanism to preserve contexts across logically-connected sync/async code execution. Tracing libraries like OpenTelemetry, or application frameworks can save their contexts and fetch it at a later async continuation. The proposal is expected to be integrated with Web platform APIs, to propagate async contexts across async API boundaries, e.g. I/O, timers (elaborated in web-integration document).
Additionally, there might be concerns regarding the memory characteristic of the AsyncContext that can put on an web app. The memory-management document expands on this about how AsyncContext API is designed to be non-enumerable and how an entry can be garbage-collected.
Metadata
Metadata
Type
Fields
Priority
Start date
Target date
Effort
Activity
dminor commentedon Mar 10, 2025
Niche use case
The explainer states that this API is not designed to be used by most developers, but as an implementation detail of certain third-party libraries.
The most common use case presented is enabling logging across asynchronous executions, in particular, to make the implementation of telemetry libraries easier. An AsyncContext provides an implicit parameter that is preserved and restored across asynchronous calls. It is possible to duplicate this functionality by using an explicit parameter to capture state. That usable libraries can be written without AsyncContext is demonstrated by the fact that libraries like OpenTelemetry currently have support for the browser, at least at an experimental level.
Library authors represent only a small percentage of JavaScript developers, nevermind the overall number of users of the web. Supporting the AsyncContext API would make life easier for them, but at the cost of pushing the underlying complexity into the web platform, where bugs would affect all users of a particular browser implementation, rather than just users of sites that use these libraries.
Developer complexity
Although not intended by the proposal authors to be used by most JavaScript developers, once it’s added to the web platform, developers will attempt to use it.
The proposal distinguishes between registration time and causal time contexts, where registration time is the context current at the time a callback is registered with an API, and causal the AsyncContext current when the corresponding event is triggered. Although the intention is to use causal context as much as possible, there are exceptions, and the decision as to which context to use is not always evident. Keeping track of which context will be used with each API is a source of developer complexity.
This proposal is also a potential source of difficult to trace memory leaks. Any API that uses a registration time context is a potential way for a developer to accidentally leak memory if they are not careful about what is stored in the AsyncContext. Again, maintaining a mental model of which APIs are registration time and which are causal time is required, which is a source of developer complexity.
Implementation cost
This proposal affects every DOM API that involves enqueueing tasks. The web integration document describes how AsyncContext could be implemented for various groups of DOM APIs, but this hides somewhat the underlying complexity of implementing this feature for every affected API. We expect it will be very costly to implement this feature in the web platform. We are concerned that the complexity of the proposal could be a source of correctness bugs leading to security problems for users.
Suggested position: negative
Although there are valid use cases for AsyncContext in the web platform, the use cases presented so far have focused on library authors. Implementing this proposal would move complexity that is currently handled by library authors into the browser, which while beneficial for the authors and users of those libraries, is not necessarily beneficial to the web platform as a whole. We do not see the use cases currently presented as sufficient to justify the large cost of implementing this proposal.
AlbertMarashi commentedon Mar 20, 2025
AsyncContexts would enable amazing advancements where it is necessary for tooling or frameworks to introduce contextual isolation between execution of code.This ranges from, and allows features and capabilities such as:
the
AsyncLocalStorageprimitive is widely supported across all major server run-times and has invaluable benefits on the serverside. It may be true that many of these things would greatly benefit library authors, and would perhaps be a little more niche for the typical developer.However, that being said, virtually every single web developers uses such libraries and tooling to build applications and websites.
The reason I believe this proposal should be considered is because it enables paradigms and systems that are currently impossible to achieve.
Attaching state to a JavaScript task obviously enables significantly more capabilities that aren't typically possible, or at least in a way that maintains developer ergonomics.
trentm commentedon Mar 26, 2025
@dminor A comment on this, as an OpenTelemetry JS maintainer. I'd challenge that OpenTelemetry's browser support demonstrates acceptable/usable async context tracking.
The async context tracking done in the browser for OpenTelemetry relies on zone.js, which (IIUC) relies on monkey-patching
Promise(and other APIs). It cannot work withasync/awaitsyntax, which relegates the current async context tracking to living in ES2015. There is no solution for more modern JavaScript. The current answer that OpenTelemetry provides for users is "you must transpile down to ES2015" or "move along without async context tracking".dminor commentedon Mar 26, 2025
That's helpful feedback, thank you.
littledan commentedon Mar 26, 2025
Some quotes from web framework maintainers explaining their need for AsyncContext: https://github.com/tc39/proposal-async-context/blob/master/FRAMEWORKS.md
js-choi commentedon Apr 8, 2025
dminor commentedon Apr 8, 2025
In the absence of a "none of the above" option in the survey, I think we have to be careful about how we interpret those results. I'm not sure I'd call 9.13% significant interest, given that
map.getOrInsertgot about 7% of the vote, and both are near the bottom of the results.If we think that there's general developer interest in using the feature directly, I think that makes the complexity concerns more relevant. One of our concerns is that misusing AsyncContext will make it easy for people to create difficult to track down memory leaks, and the usage with web APIs as currently documented (e.g. the distinction between registration and causal contexts) is fairly complicated.
AlbertMarashi commentedon May 12, 2025
Honestly it's pretty disappointing that such a valuable feature - which pretty much every modern frontend wants, and which would benefit developers would be marked as negative.
Memory leaks are something that can happen in any program, and it's always been a responsibility of developers to avoid - I don't understand how that's a valid concern, truthfully.
petamoriken commentedon May 12, 2025
NOTE: It was shared at the April 2025 TC39 meeting that the AsyncContext specification has been updated due to memory leak concerns.
https://docs.google.com/presentation/d/1YkSQIWxCQCLSe1WKFWpndEd-gdf9coE1HRYa_v_z5J0/edit#slide=id.p
vputsenko commentedon Sep 2, 2026
NodeJs can, but browsers cannot )
nicolo-ribaudo commentedon Oct 12, 2026
I just submitted a PR for the HTML integration of this proposal, so that it can be reviewed based on concrete spec text: whatwg/html#13063
zcorpan commentedon Oct 27, 2026
Reopening by request by @Bas-moz