So there are two cases.

1. User registered the click event handler in zone1, and user click the button with mouse, the click behavior happens in a noop zone (the default zone), and the handler should run in the registered zone.
2. User registered the click event handler in zone1, and user trigger the zone programmatically with something like dispatchEvent in zone2, so in this case, it is confusing that which zone should the handler run into, from the zone.js unified policy perspective, it should be zone1, otherwise in the 1st usecase, the handler should run in the noop zone, but some user may want to see zone2 in some scenario.

I still belive the current policy (run callback in the register zone) make more senses, and maybe in some cases let use can also access both the register zone and the trigger zone will be better.

The exit is the end of the scope function

Which means there’s a leak until the end of the function. https://gist.github.com/jridgewell/4aa2d6458f41d4574d6aeb580dc80d5d

And yes, there most certainly is a way to know when execution ends: any time the runtime would become idle and/or transition to microtask processing it knows it has reached the end of the current selection of synchronous code.

How do you propose expsoing this API to libraries?

However, you don't actually need to know when an end occurs if all execution descends from a root at the beginning of execution as then the start of any execution would be propagating and therefore swapping out the context value anyway

This doesn’t fully remove the need for the above end of task detection, becuase the last object placed there can’t be freed until the event loops replaces the context. It also means that Jobs would place an empty context when they return, which is OK I guess.

Hello! Chengzhong Wu told me to join here :D

We can have the same sort of scoping mechanism we have already, just remove the value setting part from it. So users can use exactly the example I shared above:

store.defineScope(() => {
  store.setForCurrentScope('foo')
})

You can know synchronously if the value still needs to be held. If an async task is scheduled in a sync tick where that context is set then it is captured to be propagated. This creates a GC reference that holds it open. If a sync tick doesn't create any further async tasks then it knows at the end of that sync tick that it created no new references.

In branching scenarios you would get each branch flowing up to exactly where it stops directly causing async code and then would have no more references. Each sync tick would only hold the reference while running, and then each async task would hold a reference until it would run. After the task runs it can discard its reference, but that would happen after new references were created for any children. Thus the GC would just function as-normal.

Now it is the case that data might live quite a long time sometimes, but this is intentional as it will only live long if descending execution of that point in context continues for long so it should be holding that value as anywhere in that descending code should be able to retrieve that data.

The risk of things living super long though is also easily mitigated by just emptying the context in some way, such as setting it to undefined when you've decided you're done with it.

My point is that in a correctly formed set/get system with clearly defined execution boundaries you would get a context flow that is perfectly safe from a memory usage perspective, have equivalent security characteristics to what is being proposed now (especially if a user-usable scope definition interface is added, and most importantly would actually match the behaviour which basically every user of AsyncLocalStorage (which is a lot--literally every single Fortune 500) is expecting from it.

Hello! Chengzhong Wu told me to join here :D