2025-11-11 [17:39:21.0045] How do we not have an example in the README using `await`? [03:43:00.0918] https://github.com/tc39/proposal-async-context/pull/140 [03:43:35.0976] It's mentioned in the motivation, and there is a paragraph specifically about await... but you are right, there is no example on it [14:57:45.0048] Ty 2025-11-13 [10:00:33.0869] I was discussing the Governor proposal with some folks and someone mentioned a question of how it worked with AsyncContext and the async iterator helpers. In particular, my understanding (though I could be wrong) is that there's a slight mismatch between iterator helpers and hypothetical generator-based implementations of those helpers - in particular iter.map() runs the function in the same context that called next() whereas the trivial function* map() would run the mapper in the initial caller's context. I would assume the async iterator helpers will be similar - are these assumptions/understandings correct? [10:10:00.0487] (or are we planning to specify registration-time context for (async) iterator helpers?) [14:55:21.0687] > <@stephenhicks:matrix.org> I was discussing the Governor proposal with some folks and someone mentioned a question of how it worked with AsyncContext and the async iterator helpers. In particular, my understanding (though I could be wrong) is that there's a slight mismatch between iterator helpers and hypothetical generator-based implementations of those helpers - in particular iter.map() runs the function in the same context that called next() whereas the trivial function* map() would run the mapper in the initial caller's context. I would assume the async iterator helpers will be similar - are these assumptions/understandings correct? Yes it matches those assumptions [14:56:33.0823] (and talking with the observables champion, this week we agreed that observables behave consistently with that btw) 2025-11-19 [17:29:53.0539] RGN just mentioned the idea that "all async iterator cleanup solutions are isomorphic to each other" e.g. resolving a promise when it's done - but this reminds me of a discussion I brought up earlier about using promises to simulate events - when async context is involved, the isomorphism potentially breaks down if you want the cleanup to happen in the same context as the job itself... [17:39:34.0967] The simulation of events with promise is not an exact simulation though, particularly about the execution time of the handlers. Promises forces deferral of the handler execution time. Another common pitfalls is that `event.preventDefault()` does not work after `await` [17:39:41.0041] * The simulation of events with promise is not an exact simulation though, particularly about the execution time of the handlers. Promises forces deferral of the handler execution time. Another common pitfall is that `event.preventDefault()` does not work after `await` [19:35:20.0358] sorry, I don't mean general-purpose event simulation - but exposing event-like things using promises _instead of_ events because it's a nicer API to code against. But the mismatch as I see it is that "event-like" things want dispatch context and promises hide that context. Same situation potentially with these async iteration cleanups - choosing to expose it via a promise may be "isomorphic" in some senses, but with AsyncContext in the mix, it has very real differences.