Stephen Belanger

Seems there's a plugin system now, so presumably someone could pick this up now?

I would be favour of it being a WeakMap. While it _is_ true that generally stores will exist for the life of the program, it's also true that in an...

It generally _would_ be eternal, but some may (mistakenly) create a store per-request as per the example. In _most_ cases this should be fine and naturally disappear eventually as snapshots...

The counterpoint is that while it _is_ a leak, a broken connection pool is going to just keep leaking the same store forever, not a new store every time, so...

AsyncLocalStorage not taking a receiver is generally considered to be a mistake, which is why other related things like diagnostics_channel _do_ take receivers.

So the main reason for it is to enable store.run(...) to universally be able to replace a call without additional closures. For example, foo(bar, bar) can directly become store.run(context, foo,...

Yes, it is the case that often closures will be used by users, but they're also expensive if the run happens in a hot-path so I think we should consider...

Passing in Reflect.call seems reasonable to me, so long as we keep the argument pass-through so we can avoid a closure wrap or a bind-and-then-call when we care about performance....

There is always a valid originating context, it's just not necessarily directly synchronously calling the continuation. For example, in all those XMLHttpRequest cases the originating context would be when the...

> That is not the case. In the browser, a user-initiated click event does not have an originating context (other than the empty one), simply because there's no JS code...