Focus on What Hurts Most: AsyncContext for await as a First Step

[dfahlander]

Suggestion for Narrowing Scope of AsyncContext to Its Core Use Case (for TC39 108th Meeting)

In light of @andreubotella’s upcoming presentation “How to simplify the web integration”, I’d like to respectfully propose narrowing the initial scope of the AsyncContext proposal to the most critical and unpolyfillable parts of async context propagation — namely async/await and Promises (and possibly async generators).

I raised a related issue earlier (#65) and, while it received some pushback at the time, I’d like to reintroduce the idea for further consideration. My intention is to help ensure this proposal delivers maximum impact with minimal complexity.

A Personal Stake: Dexie.js and Its Limitations

As the author of Dexie.js — a widely used IndexedDB wrapper featured in apps such as ChatGPT, WhatsApp Web, and Facebook Messenger — I deeply appreciate this proposal. Dexie uses its own internal async context to manage transactions and live queries. However, due to the absence of a standard, Dexie cannot interoperate with libraries like OpenTelemetry or Zone.js, which rely on their own workarounds.

This incompatibility directly stems from the lack of a consistent, standard way to track async context across await boundaries. Dexie and many other libraries don’t need the full machinery of async context for every possible async API — just async/await and Promises.

---

Focus the Proposal on What Cannot Be Polyfilled

A minimal version of AsyncContext — one that only targets native Promises and await — would provide immense value and interoperability across libraries. It would also:

• Accelerate browser vendor adoption
• Reduce cognitive overhead for developers
• Preserve room for future opt-in complexity (e.g., setTimeout, EventTarget, etc.)

Libraries like Zone.js have already demonstrated that most web APIs can be polyfilled effectively — except await. That one gap is what this proposal is uniquely positioned to fill.

---

What Would React Do?

The React section in FRAMEWORKS.md points out that startTransition() loses context only across await. If this proposal focused solely on Promises and await, React’s issue could be addressed without introducing additional complexity. Limitations (e.g. lack of support for timers or event listeners) could be clearly documented for now.

---

What About Solid, Svelte, and Vue?

As reflected in FRAMEWORKS.md, these frameworks primarily care about preserving context across await. Supporting that alone would already unblock many current use cases.

---

What About OpenTelemetry?

OpenTelemetry for web depends on Zone.js, which successfully polyfills all but one async behavior: await. This single missing link means users must transpile all their async functions — a fragile and complex workaround.

By standardizing async context for await, we can eliminate this barrier and provide out-of-the-box support for libraries like OpenTelemetry in the browser — a major win for both observability and DX.

---

Can Implicit Context Propagation Be Added Later?

Yes, the proposal’s current form already leaves the door open to future extensions. For example, AsyncVariableOptions could be extended in the future with an additional option such as captureLevel, enabling opt-in deep propagation when desired.

This path allows TC39 to ship a minimal core that solves the hardest problem now, while keeping future complexity opt-in and backwards-compatible.

---

Conclusion

A narrowly scoped AsyncContext — focused on await and Promises — would already unlock massive value for libraries, frameworks, and developers, while simplifying both implementation and mental models.

Thank you for the ongoing work on this proposal. I’m happy to elaborate further or assist in any way that’s helpful!

[andreubotella]

Focus the Proposal on What Cannot Be Polyfilled

A minimal version of AsyncContext — one that only targets native Promises and await — would provide immense value and interoperability across libraries. It would also:

* Accelerate browser vendor adoption

* Reduce cognitive overhead for developers

* Preserve room for future opt-in complexity (e.g., `setTimeout`, `EventTarget`, etc.)

Libraries like Zone.js have already demonstrated that most web APIs can be polyfilled effectively — except await. That one gap is what this proposal is uniquely positioned to fill.

For what it's worth, some of the aspects of the current web integration proposal would be very hard to polyfill. For example, if you do window.onmessage = () => { /* ... */ }, the context in which that callback will be run depends on the context that called window.postMessage().

I believe the way Zone.js polyfills that is by patching everything so that the actual message sent contains a context ID, and by patching EventTarget and the various event handlers so that calling addEventListener or setting onmessage instead passes through a Zone.js hook that reads that message and sets the right context. This would also mean the Zone.js-equivalent library would need to keep an ID -> context map for all contexts that are passed to some similar web API, which for some APIs (although not for this one, I believe) could lead to memory leaks if there's a chance the equivalent to the message event won't be fired.

I believe there might also be cases where there really would be no way to polyfill the context accurately in userland, but I don't have any examples of that right now.

---

Can Implicit Context Propagation Be Added Later?

Yes, the proposal’s current form already leaves the door open to future extensions. For example, AsyncVariableOptions could be extended in the future with an additional option such as captureLevel, enabling opt-in deep propagation when desired.

This path allows TC39 to ship a minimal core that solves the hardest problem now, while keeping future complexity opt-in and backwards-compatible.

The main problem we're having with the web integration part of this proposal isn't that it needs to be done together with the await part of the proposal. It's that 1) there's a lot of complexity in figuring out how everything should behave, and 2) there's potentially a lot of complexity in implementing all of it, which Mozilla doesn't think is worth it. (To be fair, there might be more motivation for that if Mozilla sees the need after the await part is shipped, but considering everything, I doubt it.)

Even if we add at some later point a deep propagation flag, the problems of figuring out how everything should behave, and the complexity of implementing it all at once don't go away. Even if we add deep propagation later on with such a flag, the entirety of the deep propagation would need to be added at once. Otherwise, rather than a flag, you'd need to have something like a version level, which would need to be increased with every single incremental update to how the web integration works.

[lifaon74]

I agree with @dfahlander. Currently, the main issue stems from async/await, which simply cannot be polyfilled (to work with AsyncContext or similar) without transpilation tools like Babel—such as @babel/plugin-transform-async-to-generator used for ES2017.

At present, the specification attempts to unify "all things async" under one umbrella. However, while asynchronous APIs like setTimeout can be patched, async/await cannot. In my view, unless we significantly reduce the initial scope of the proposal, this could delay—or even prevent—its adoption by TC39.

[Qard]

While async/await is the hard-stopper (relatively speaking, anyway...you can still do AST transforms, but that's a lot of work) for implementing context management presently, there are many more situations which are deceptive in their complexity.

Also, implementing such functionality substantially via monkey-patching is massively costly, which is why I spent literally years tuning the AsyncLocalStorage implementation in Node.js to something that has actually acceptable enough performance to be usable. Before all that work, async context management in Node.js typically had 500%+ overhead. 😬

To be frank, I don't think having async context management in the language will be useful at all if we half-ass it. Do it right, or don't do it at all. It'd be a huge miss to skip out on it though as it provides significant benefits to observability and to decoupling power of the language. When you've worked with context management as much as I (or most others in the Observability space) have, you struggle to imagine how any language could not have context management at this point--it's such a fundamental need for production code.

[dfahlander]

Just saying that if (and only if) the complexity kills or delays this proposal, please go forward with a plan B and I also want to kill the myth that this couldn't be extended later, quoting this part of my original post:

Can Implicit Context Propagation Be Added Later?

Yes, the proposal’s current form already leaves the door open to future extensions. For example, AsyncVariableOptions could be extended in the future with an additional option such as captureLevel, enabling opt-in deep propagation when desired.

This path allows TC39 to ship a minimal core that solves the hardest problem now, while keeping future complexity opt-in and backwards-compatible.

[andreubotella]

Just saying that if (and only if) the complexity kills or delays this proposal, please go forward with a plan B and I also want to kill the myth that this couldn't be extended later, quoting this part of my original post:

Can Implicit Context Propagation Be Added Later?

Yes, the proposal’s current form already leaves the door open to future extensions. For example, AsyncVariableOptions could be extended in the future with an additional option such as captureLevel, enabling opt-in deep propagation when desired.
This path allows TC39 to ship a minimal core that solves the hardest problem now, while keeping future complexity opt-in and backwards-compatible.

I don't really see this as feasible. Currently we spec this (and plan to implement it in various browsers) as there being a single global map that contains the current mappings from AsyncContext.Variable keys to their current values. This global map can be implemented as being immutable, so a new one would be created whenever you call .run, but context propagation would simply keep track of a single pointer to the map that's being propagated.

Your proposal would need a different map for each capture level. If we were talking about two capture levels (say, 0 meaning await and promise, 1 being the whole web platform), this might not be unfeasible, but you'd have to ask browsers. But having multiple capture levels, I don't see that working.

[dfahlander]

Basically falling back to a limited proposal (without the whole web platform) would not leave us screwed forever, as a new level could be added in upcoming proposal. It would require two maps at that point but it would be doable.

[lifaon74]

I would add that, regardless of the approach, this extension will never be able to cover everything. For example, in the future, a new type or asynchronous function might emerge - one that we may or may not want to be handled by AsyncContext. In any case, this new type would have to be added explicitly. Therefore, it seems reasonable to start with the simplest case (async/await), and then extend support incrementally as needed.

In any case, this suggestion is primarily intended to enable a faster and simpler adoption of a solution to an issue that is currently a blocking point. It would be unfortunate to end up in a situation similar to that of decorators - trying to do too much - and still not being ratified after many years. That said, I leave it to the authors to judge the situation, as they are the ones most familiar with the context.

[Qard]

Async context management, to function correctly should support basically every case of async execution. If there was a case in the future where we explicitly did not want context propagated (for security reasons, maybe?) that should be an explicit decision at that time. It should propagate automatically by default in every case unless we explicitly specify it not to do so. Specifying the exceptions make a lot more sense than specifying every single case individually with something this universal.

We should be specifying:

1. Any time async anything happens, propagate context
2. In x set of specific circumstances we have deemed context should not be propagated
3. Every case of asynchrony which is currently vaguely specified should be made explicit that it is asynchrony and therefore any rules for asynchronous behaviour (such as those from async context management) should apply