| 17:37 | <littledan> | Where are we in understanding https://github.com/tc39/proposal-async-context/issues/83 ? |
| 18:42 | <Mathieu Hofman> | I talked with Dean Tribble on Friday, picking his brain from his Midori experience. I think the conclusion is that there is no way to abstract "calling" context in an API shape like AsyncContext. The biggest problem is that the most recent calling context may not be the one you really need, that providing more than one would result in unbounded calling context history, and that it would expose some implementation details about the execution order of the "callers". For telemetry / debugging use cases, one approach is to gather points at certain key times. For promises for example, you can give them an ID and "log" when they are resolved (potentially to another promise), when reactions are added and executed, etc.. Then you can correlate all this and recompose your execution graph. this of course sounds very similar to async_hooks, and is too powerful of an API to expose to "unprivileged" code. |
| 19:03 | <littledan> | I talked with Dean Tribble on Friday, picking his brain from his Midori experience. I think the conclusion is that there is no way to abstract "calling" context in an API shape like AsyncContext. The biggest problem is that the most recent calling context may not be the one you really need, that providing more than one would result in unbounded calling context history, and that it would expose some implementation details about the execution order of the "callers". For telemetry / debugging use cases, one approach is to gather points at certain key times. For promises for example, you can give them an ID and "log" when they are resolved (potentially to another promise), when reactions are added and executed, etc.. Then you can correlate all this and recompose your execution graph. this of course sounds very similar to async_hooks, and is too powerful of an API to expose to "unprivileged" code. |
| 19:04 | <littledan> | "just choose something for each case" is the strategy that I was imagining; maybe too naive but it sounds like this is maybe what Dean is saying? |
| 19:06 | <littledan> | I'm wondering if there's any way we could expose "just" the necessary information to hook up the extra follows-from links, or distinguish child vs following links. I think Stephen Belanger may have been asking for one of these, though I'm not sure. Did you discuss this topic with Dean? |
| 19:12 | <Mathieu Hofman> | Yeah having a default of "snapshoting" at registration makes sense for AsyncContext. It's just that AsyncContext might not be the right API shape for telemetry use cases. And yes we tried to figure out how the necessary info could be exposed through AsyncContext, but couldn't find a way. |
| 19:14 | <littledan> | I think the current shape of AsyncContext has a "good enough in practice" shape for telemetry since it matches what's done in Node.js today. Maybe something better is possible; certainly telemetry infrastructure can be trusted. |
| 19:15 | <littledan> | Mathieu Hofman: Do you think we should continue with AsyncContext as currently proposed, without changes like #83? |
| 19:32 | <Steve Hicks> | Are we also considering taking the smaller-scoped callingContext API off the table? |
| 19:33 | <Steve Hicks> | #83 has made me pretty concerned about scope creep. But I'm also obviously concerned about my own pet use cases. I've got a meeting with Jatin this evening to hopefully nail down exactly what kind of registration- vs. call-time semantics we will need. |