James Browning

Given that if an `AsyncContext.Snapshot` that hasn't been GCed could be used, surely the only way earlier detection would be possible is if there is some `.discard` or such on...

I made a little [proof of concept](https://gist.github.com/Jamesernator/01b0ad45016d8e5658c76e6811449181) of what I described above using Node's `async_hooks`. A small example demonstrates that this pattern can in fact observe essentially the exact timing...

> but will miss the case where all outstanding continuations (both one shot and reusable) are collected, and the context is effectively terminated. Well for some prior art, Node's `AsyncResource`...

> The program can arrange that this object not be referenced anywhere but through the AsyncContext mechanism, which means the only path to observe its value would be through `variable.get()`,...

I strongly think that events should use registration time *by default*. Like from a user's perspective if we have some code like: ```js someScheduler.runTask("highest-priority", async () => { // some...

> But this is essentially the same as mutating a context in a child call and expecting it to be present in the parent execution: > I think making this...

Perhaps there should be second kind of variable (or option to `AsyncContext.Variable`) specifically designed for tracing-like use cases. (Regular variables would not hold onto their calling context). i.e.: ```js const...

> This is exactly what should be happening. No, this is completely unusable for all the non-tracing use cases, the whole point of `AsyncContext` is that users don't want to...

Just to give an example of why the proposed behaviour is completely unusable, consider for example the dependency injection use case: ```js // In practice the logger would be a...

> A default can and should be chosen in the general case, but we need flexibility or the feature will be useless even for the basic application developer use case...