async_hooks: add use() method to AsyncLocalStorage
This provides a way to use the using syntax (when available) to manage AsyncLocalStorage contexts, as an alternative to run().
Codecov Report
Attention: Patch coverage is 87.75510% with 6 lines in your changes missing coverage. Please review.
Project coverage is 90.21%. Comparing base (
102d8cf) to head (b0bc07a). Report is 462 commits behind head on main.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| lib/internal/async_local_storage/async_hooks.js | 80.64% | 6 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #58104 +/- ##
=======================================
Coverage 90.20% 90.21%
=======================================
Files 630 630
Lines 186446 186495 +49
Branches 36622 36629 +7
=======================================
+ Hits 168189 168246 +57
- Misses 11051 11058 +7
+ Partials 7206 7191 -15
| Files with missing lines | Coverage Ξ | |
|---|---|---|
| ...nternal/async_local_storage/async_context_frame.js | 100.00% <100.00%> (ΓΈ) |
|
| lib/internal/async_local_storage/async_hooks.js | 94.94% <80.64%> (-3.02%) |
:arrow_down: |
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
Failed to start CI
β No approving reviews found β Refusing to run CI on potentially unsafe PRhttps://github.com/nodejs/node/actions/runs/14782552537
π€¦ -> closing https://github.com/nodejs/node/pull/58019 in favor of this
@legendecas
Like https://github.com/nodejs/node/pull/52065, i think this does not work with an async function before the first await that the value will leak out the async function scope. This will need a patch to make V8 CPED aware of async function scopes as well.
Do you see that as a blocker? Or would it just be fine to document this limitation for now?
Do you see that as a blocker? Or would it just be fine to document this limitation for now?
I would not see it as a blocker on this particular PR. It would be great to have this PR landed with this API marked as an experimental (1.1 Active development) API and with the limitation documented as a caveat. I think to promote this to stable, we'll need this semantic as a blocker.
I never got around to merging this but I have a fix for the CPED issue: https://chromium-review.googlesource.com/c/v8/v8/+/6020635
@devsnek do you think you could find some time to pick it up again and finish that? :)