TC39 Async Context on 2023-01-26

00:16	<James M Snell>	Except that doesn't work with error stack properties yet :-/ (as we discussed earlier)
00:17	<Justin Ridgewell>	Yah, only dev tools
07:16	<Chengzhong Wu>	Agreed. I tried to find an exact definition of "fluid variable" but no luck for me.
07:22	<Chengzhong Wu>	We have an issue on generator use case in OpenTelemetry too: https://github.com/open-telemetry/opentelemetry-js/issues/2951
07:23	<Chengzhong Wu>	I'll create the issue then.
07:38	<Chengzhong Wu>	https://github.com/legendecas/proposal-async-context/issues/18
17:38	<Chengzhong Wu>	Would you mind expanding on "rename run()"?
17:51	<James M Snell>	Just for visibiity... WinterCG discussed defining an interoperable subset of AsyncLocalStorage ... draft is here https://github.com/wintercg/proposal-common-minimum-api/pull/38
17:52	<James M Snell>	the idea is to define a minimal subset of the API that runtimes can implement now while waiting for AsyncContext to be finished
17:52	<James M Snell>	the subset is intended to be minimally compatible with the model being defined here in order to prevent incompatibilties down the road
18:26	<Justin Ridgewell>	I think he's referencing the module-level run helper function, not the `AC.p.run` method
18:27	<Justin Ridgewell>	We could call it `doRun` or something short
18:28	<Justin Ridgewell>	the subset is intended to be minimally compatible with the model being defined here in order to prevent incompatibilties down the road I think we're going to have an issue with `EventEmitter`/`EventTarget`
18:29	<Justin Ridgewell>	My expectation on the web side is that `addEventListener` will act as an async resource and capture the current frame to be used when the event is emitted
18:36	<James M Snell>	I've had this pop up in other conversations also. I'm fine if we do that but it does introduce an incompatibility with Node.js, which does not currently propagate the context for either of these
18:37	<James M Snell>	We have greater flexibility/authority to define the behavior for `EventTarget` here than `EventEmitter`, which is a node.js defined API
18:38	<James M Snell>	but we can definitely raise this. one concern I know will come up with `EventEmitter` is that with the current async_hooks based design, there's going to be a performance hit
18:38	<James M Snell>	but that's an implementation specific concern
18:38	<James M Snell>	can I ask you to comment in the PR on this?
18:39	<littledan>	My expectation on the web side is that `addEventListener` will act as an async resource and capture the current frame to be used when the event is emitted This doesn't match my expectation. I think Andreu Botella is investigating this sort of issue.
18:39	<littledan>	I think addEventListener will sometimes act like this, and sometimes not
18:39	<Andreu Botella>	investigating that is on my TODO list
18:41	<littledan>	anyway I don't think solving this problem should block Deno and Cloudflare from shipping their AsyncLocalStorage subset
18:41	<James M Snell>	Sadly this one is pretty complicated. there are three distinct modes: Capture the context on EventTarget/EventEmitter creation (extends AsyncResource style, ala Node.js `EventEmitterAsyncResource`) Capture the context on addEventListener/on (e.g. AsyncResource.bind() / wrap()) Use the current context when dispatchEvent/emit is called.
18:42	<James M Snell>	The subset as currently described allows all three, with 3 being the default. Making either of the other two the default makes 3 more difficult (or even impossible?)
18:42	<littledan>	Mostly I think this because I think they, like everyone who has shipped this feature, will have a long stream of bug reports about expectations being subtly broken and they will iterate a bit over time
23:25	<Justin Ridgewell>	Ben Newman (Apollo, @benjamn on GH): do you want to submit your thenable patch to V8?