Review requested:

• @nodejs/gyp
• @nodejs/startup

Also worth considering that as this no longer depends on async_hooks in any way it might make sense to give it a separate module name at some point too and just have async_hooks re-export it.

Some additional notes:

• This will have to be behind a build flag because of a conflict with Chromium using the same single-tenant API in Electron.
• I have not yet wired this up to AsyncWrap. It will need some linkage there to actually work across real async boundaries.
  • current() and exchange() are exposed on the C++ side to make this straightforward but may do some scope helpers for that. We'll see if it's necessary.
• I also need to make a PR to V8 to make it propagate embedder data through thenables.
• There are probably still lots of bugs and the existing tests don't have great coverage. I'll improve those while I'm working on this as I want to be sure we're not breaking any edge cases.

Woo! Thanks for getting this started. The need for the flag is unfortunate but definitely required given how chromium is using the API and the conflict that causes with electron. But otherwise this should be a major improvement over the current state. Will do a thorough review this weekend.

Another note:

This currently uses a model of building a linked-list of AsyncContextFrames which each contain only the key and value they were constructed with. The alternative which is what was originally proposed was to use a map which is cloned from the parent frame at each frame construction and then the single additional entry for that frame is added but it is considered otherwise immutable.

I went with the current model mostly because it was easier and made debugging simpler but I plan to spend some time benchmarking the two approaches to identify the trade-offs and figure out which approach would be generally better. The one definite downside to the current model is it holds past values for the same store from further up the call graph alive longer which may be undesirable but may only really apply to top-level scopes that will need to be kept alive anyway.

Further analysis should provide some better insight into the behaviour.

This is awesome!

Also worth considering that as this no longer depends on async_hooks in any way it might make sense to give it a separate module name at some point too and just have async_hooks re-export it.

That'd be a welcome change. We've been trying to eliminate async_hooks usage in our apps (as we've detected performance issues when async_hooks are misused), and having to import AsyncLocalStorage from the async_hooks module messes with how we detect if an app is using async_hooks or not.

Thenables propagation fix is here: https://chromium-review.googlesource.com/c/v8/v8/+/4674242

I propose tagging this as semver-major.

@mcollina Could do that. Though the way in which we land it is still not entirely decided. Due to the Electron conflict it needs build-flagging anyway, so this could be landed as a minor if it's by default turned off. It could land off by default and then have a follow-up to turn it on by default as a major. What do you think?

That works

I've got all but four two of the existing tests passing at this point:

• thenables I have a fix for this here.
• http.Agent, which I haven't yet figured out why my existing AsyncResource patches don't cover it.
• storage.disable(), which currently only blocks propagation after the call but also needs to block for the rest of the tick before the call too in order to pass the existing tests.
• unhandledRejection, which does not match the context of the promise. James said he'll point me at how Cloudflare did it.

Hi, @Qard, Can you explain how the API v8::SetContinuationPreservedEmbedderData(...) work ? I have read some docs and code, but I don't understand it very well, thank you ! It looks a bit like SetEmbedderData/GetEmbedderData API.

The SetContinuationPreservedEmbedderData API stores a v8::Value in the v8::Context. Whenever a promise reaction job is created (meaning when it resolves or rejects) it captures the value held at that time and stores it on that reaction job. Whenever the reaction job runs (meaning a then/catch/finally continuation runs) it restores that value as the current stored value and then reverts to the previous value when the job is done.

This is essentially what async_hooks does currently with executionAsyncResource but exclusively for promises. However we can also manipulate that current value externally to capture and restore the value around AsyncWrap, AsyncResource, and any other scope we need to manipulate to match our execution flow.

I've now got the builtins working against active context rather than creation context. With that all existing tests are now passing. Final benchmark results are:

                                                                                        confidence improvement accuracy (*)     (**)    (***)
async_hooks/async-local-storage-getstore-nested-resources.js n=10000 resourceCount=10          ***     37.01 %       ±5.19%   ±6.91%   ±9.00%
async_hooks/async-local-storage-getstore-nested-resources.js n=10000 resourceCount=100         ***     19.49 %       ±2.97%   ±3.96%   ±5.15%
async_hooks/async-local-storage-getstore-nested-resources.js n=10000 resourceCount=1000        ***      7.55 %       ±3.28%   ±4.36%   ±5.68%
async_hooks/async-local-storage-getstore-nested-run.js n=10000 storageCount=1                  ***     25.97 %       ±2.66%   ±3.54%   ±4.62%
async_hooks/async-local-storage-getstore-nested-run.js n=10000 storageCount=10                 ***     28.12 %       ±2.37%   ±3.16%   ±4.13%
async_hooks/async-local-storage-getstore-nested-run.js n=10000 storageCount=100                ***     10.92 %       ±2.90%   ±3.86%   ±5.03%
async_hooks/async-local-storage-propagate-asyncresource.js n=1000 storageCount=0               ***     11.72 %       ±2.49%   ±3.32%   ±4.33%
async_hooks/async-local-storage-propagate-asyncresource.js n=1000 storageCount=1               ***    137.10 %       ±3.89%   ±5.20%   ±6.81%
async_hooks/async-local-storage-propagate-asyncresource.js n=1000 storageCount=10              ***    263.46 %       ±5.99%   ±8.07%  ±10.70%
async_hooks/async-local-storage-propagate-asyncresource.js n=1000 storageCount=100             ***   1650.06 %      ±41.27%  ±55.62%  ±73.83%
async_hooks/async-local-storage-propagate-promise.js n=100000 storageCount=0                            0.16 %       ±2.10%   ±2.80%   ±3.65%
async_hooks/async-local-storage-propagate-promise.js n=100000 storageCount=1                   ***    195.33 %       ±3.87%   ±5.21%   ±6.90%
async_hooks/async-local-storage-propagate-promise.js n=100000 storageCount=10                  ***    807.12 %      ±11.39%  ±15.35%  ±20.38%
async_hooks/async-local-storage-propagate-promise.js n=100000 storageCount=100                 ***  14494.18 %     ±190.06% ±256.14% ±340.05%
async_hooks/async-local-storage-run.js n=10000000                                              ***     41.39 %       ±1.67%   ±2.22%   ±2.89%

Be aware that when doing many comparisons the risk of a false-positive result increases.
In this case, there are 15 comparisons, you can thus expect the following amount of false-positive results:
  0.75 false positives, when considering a   5% risk acceptance (*, **, ***),
  0.15 false positives, when considering a   1% risk acceptance (**, ***),
  0.01 false positives, when considering a 0.1% risk acceptance (***)

I'll get started on a CR to add the builtins to V8 and will update this again once we can get the changes for that and thenables support backported.

I've submitted a V8 CR to add the TurboFan builtins for the get/set functionality. I'm also still waiting for reviews on the thenables fix. Feel free to review/comment on either. Once those both land I'll get them backported to Node.js and then update this PR. 🎉

How would people feel about this being behind a runtime flag rather than a build flag? I'm trying to figure out how to get CI testing against both implementations and it seems like it would be a lot easier if it was a runtime flag instead. I feel like it should be fine as the conflict with Electron would only happen if we actually call the get/set functions so we could just escape before those would be run and have basically the same behaviour as we have now. 🤔

The actual changes to the original version are very minimal as the new version is basically entirely standalone. The only really notable change is just moving some things out to separate files and the mode switching on detection of the AsyncContextFrame class.

As long as I configure it to never call the set/get functions in either C++ or JS, it should actually be safe to land as a minor behind a flag, at least in my opinion. That also gives us the potential to backport which would be highly desirable for us APM providers as we could at least advise customers on older versions to use the flag for better performance in the event they have issues with the performance of the existing code.

Would be worth it to trigger https://ci.nodejs.org/job/node-test-commit-v8-linux/ since it manually patches v8.

How would people feel about this being behind a runtime flag rather than a build flag? I'm trying to figure out how to get CI testing against both implementations and it seems like it would be a lot easier if it was a runtime flag instead.

Runtime flag would be preferable if possible. We don't test every build flag in the CI. For CI runs, the majority of the time is compilation/building rather than test execution.

BTW, on vacation this week, so there won't be any movement on this until next week. Shouldn't take too long to figure out runtime flagging though. 🙂

I feel like it should be fine as the conflict with Electron would only happen if we actually call the get/set functions so we could just escape before those would be run and have basically the same behaviour as we have now. 🤔

It would not even happen unless someone turns on the runtime flag right? So I don't think conflicts with Electron would be a problem, there are probably plenty of flags out there that do not work quite well with Electron anyway...

On the other hand I wonder why the V8 API cannot use e.g. an FixedArray of continuation data, instead of just allowing one entry. The builtins can just be extended to take an index to that array. It doesn't even have to grow, a fixed number of entries may already be enough (like how each isolate only have 4 fixed data slots). That's been how we handle the multi-tenancy issue with e.g. context embedder data too (which is growable though)

I think there is a difference regarding behavior after disable.
The async hooks based implementation doesn't propagate anymore after disable() was called.
The new implementation will still propagate AsyncContextFrames even if the store is disabled.

I doubt that this difference is critical because disable is usually not the main API used in the wild and as disable is still marked as experimental we have no semver impact.