2026 AsyncContext: where are we now?

WEH 2026 - AsyncContext: where are we now?

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/78
• URL: https://meet.jit.si/WEH2026-async-context
• Slides: https://docs.google.com/presentation/d/1oxzXkr7MLbOJ5TQ1zdooYlCSBZhdrnVZmYR6CluO7XY/edit?slide=id.p#slide=id.p

Nic: I'm presenting a quick recap regarding AsyncContext. It adds utilities to implicitly propagate values through async code.

Nic: Tehre are many use cases for this, One of them is for front-end frameworks to represent which component a given code is part of.

Nic: Another use case is tracing (debug) to get applicationg logs.

Nic: There are some simple cases like async await I showed, but there are some complex scenarios as well. Most of complexity is on the Web API (WHATWG) like Signals(?), Events(?), ...

Nic: Sicne last year we worked on the proccess for WHATWG parts of the proposal, There's some spec PRs open already. So far we know how Sync APIs behave, How Promise-based APIs behave, and how APIs that signals completion with callbacks will behave. There's still work to be done on how some APIs that do some work after callbacks will behave (e.g Signals, Streams, etc)

Nic:Anotehr compelx aspect is how to properly design AsyncContext with Events API, since we need to balance how easy its to use for JS programmers and how ... (missed)

Nic: There are soem principles we are doing to design AsyncContext with events. (Slides: https://docs.google.com/presentation/d/1oxzXkr7MLbOJ5TQ1zdooYlCSBZhdrnVZmYR6CluO7XY/edit?slide=id.p#slide=id.p) - Slide 14 for Principle #1 - Slide 15 Pirnciple #2 - Slide 16, 17, and 18 is principle #3 - Slide 19, Principle #4 - Slide #20, Principle #5

Nic: Otehr work we've been doing is applying those principles on the HTML spec and seeing how things work on concrete cases. One example is what we do on load image tag and how the context is propagated there. It captures the context on image creating to restore it on loading/error events.

Nic: Another example is the video tag element. This has a larger set of events that might have. Some of those things will need that we store the context for longer. We are currently looking for feedback from users like Youtube on how some of them should be considered.

Nic: What we learned so far is that we can use those principle as guideline, but not as an enforcement.

Nic: Now we are proposing 2 new WebIDL extended attributes as callbacks (missed them).

James Snell: In nnode, on async locall storage and we have AsyncResource. Is this a TC39 poposal that will be similar to what we have in node capture the scopes and propagate it?

Nic: (missed Nic answers)

Chengzhong: AsyncContext.Snapshot is an equivalent to AsyncResource. AsyncContext.Variable is an equivalent to AsyncLocalStorage.

Nic:

Dan: This seems really great, let's ship it?

Nic:

Olli: I [dont?] like those IDL annotations.

Simon: I'm curios about the events case. When you create an element, what gets captured?

Nic: It dependes where you create the element. Wherever the creation of the elements happens, the context will then be captured and propagete to the fired event.

Simon: I'd like to understand how well would this work for different elements. I'm not sure how would they work.

Nic:

Simon: Dow we only care about the tasks to track the variables, or would MicroTasks would be considered.

Nic: There are a couple of spaces on HTML spec that it's not obivious to me if it would be need some capture, ...

Simon: So for the media elements, like video, the context would be captured at creation, and how they would be propagate?

Nic: Taking the example of playing and pause, there will be needed to hold the context, so when the events happens, we need to restore the context.

James: unhandledRejection and error

Nic: Some context on error, some cases it's useful to have access to the context where the resource got created to be handled on the rejection.

Andreu: I just realized that the PR for unhandledrejection does propagate the context, which is not what we had agreed before.

Dan When you were develeoping principles, how did you evaluate them?

Nic: We've been working with Chengzhong, from OpenTelemetry . We talked with Chomium folks. We talked with some framework people, but they often reimplement the events somehow, so whatever we do, they will need to re-implment?

Daniel: Do we have browser vendors here ??

Nic: Memory leak wise Rather than letting browser decide whether things are garbage collectable we can put that in the spec. There are user pattents possible where the event would fire but it is not guaranteed. A task could be pending forever. That frequently leaks something else.

Daniel: About the risk of memory leaks, we’ve been talking about that for 4 years. How should we go about that.

Olli: We should be very explicit when we clear the AscynContext. The annotations makes more obivious which places are affected.

Nic: Maybe we can figure out some spec language that captures this

Daniel: Great, write the spec PR!

Olli: I guess there is still some work

Nic: Yes. I've seen some other places, I don't remember all details, but most of those palces seems like simple changes.

Dan: Wait you mention observables in particular. Like unhandledRejection and errors.

Nic: Mutation observer is the more interesting one as it reacts to dom changes. Some developers would like some context there, but we can discuss that later.

James: We had a recent use case where we had an active where we basically had to stop. Not just to propagates. Explicit it stops here.

Nic: Not directly, you could capture the top level context and propagate it from it.

Daniel: async context dot snapshot dot whatever it is called, dot dot run is how you stop the propagation.

Nic: It could be possible that future specs change the default context.

Steve: Getting the dispatch context might be qutie hard (is this the default context?), while being able to snapshot and define which context the handling of a button runs is much more straight forward. So haveing this as default behavior looks to be the right direction.

Nic: I am happy with the discussion. There is more work for me to do. If anyone wants to get more actively involved we have a matrix room. It's linked in the proposal readme https://github.com/tc39/proposal-async-context/.

Nic: What do you think we need to do for WHATWG stage 2? Do we need patches for all WHATWG specs?

Simon: Start with a PR for whatwg/html, so people can see the API shape and discuss there, that should be enough for now.

Nic: our idea was HTML and DOM and ?.

Andreu: There are some changes we need to do on DOM API spec as well. In the end we will need different APIs in different specs.

Nic: Andreu is asking if there's a way to make the PRs more digestable for editors to review, because they will be large and cross-referencing each other.

Simon: at least for me big PRs are okay, if they can be layered logically than separate is also okay.

Olli: Has Webkit given any feedback?

Nic: The webkit people that gave people are not here but I would classify their thoughts as neutral/slightly leaning positive.

Andreu: we have every-2-weekly meetings, only people from Google and Igalia (and Bloomberg) show up

Nic: That’s on me, I didn’t invite them because I told Mozilla people that I’ll let them know when we need them. maybe we can reschedule.

Nic: Ok thanks everyone! Thanks everyone who gave feedback. It’s nice to see that it’s making some progress and have a possible direction to go to!