async_hooks: add using scopes to AsyncLocalStorage

[Qard]

Adds support for using scope = storage.withScope(data) to do the equivalent of a storage.run(data, fn) with using syntax. This enables avoiding unnecessary closures.

cc @nodejs/diagnostics

[Flarna]

I guess this replaces #58104 right?

[Qard]

Ah, yes. Forgot that one existed. 😅

[github-actions]

Failed to start CI

   ⚠  No approving reviews found
   ✘  Refusing to run CI on potentially unsafe PR

https://github.com/nodejs/node/actions/runs/21678728231

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.75%. Comparing base (5e818c9) to head (09cb6ad).
⚠️ Report is 17 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61674      +/-   ##
==========================================
+ Coverage   89.74%   89.75%   +0.01%     
==========================================
  Files         674      675       +1     
  Lines      204389   204428      +39     
  Branches    39280    39284       +4     
==========================================
+ Hits       183424   183480      +56     
- Misses      13264    13265       +1     
+ Partials     7701     7683      -18     

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	98.03% <100.00%> (+0.08%)	⬆️
lib/internal/async_local_storage/run_scope.js	100.00% <100.00%> (ø)

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71216/

[Flarna]

Maybe adapt to following to better verify that second call does nothing:

  storage.enterWith('test2');
  assert.strictEqual(storage.getStore(), 'test2');

  // Double dispose should be idempotent
  scope[Symbol.dispose]();
  assert.strictEqual(storage.getStore(), 'test2');

[Flarna]

Suggested change

	using scope = asyncLocalStorage.withScope('my-store');
	using _ = asyncLocalStorage.withScope('my-store');

I think this is the usual guideline if unused. Feel free to ignore.

[Flarna]

Suggested change

	using scope = asyncLocalStorage.withScope('my-store');
	using _ = asyncLocalStorage.withScope('my-store');

[Flarna]

Suggested change

	using scope = asyncLocalStorage.withScope('my-store');
	using _ = asyncLocalStorage.withScope('my-store');

[Flarna]

Suggested change

	using scope = asyncLocalStorage.withScope('my-store');
	using _ = asyncLocalStorage.withScope('my-store');

[legendecas]

We should document the caveat that this cause side effects outside of an async function scope if this is called before the first await:

async function foo() {
  using value = als.withScope(newValue);
  await 0;
}

foo() // no await
al's.getStore() // value changed.

[Qard]

Yep.

This is also exactly why I had previously suggested that AsyncContext create context boundaries around the initial segment of async functions too in order to make the set/get model work.

In my opinion the entire async function execution model is wrong until the first segment either has its own context or is made async the way the rest of the function is. It was a strange decision making execution of that initial segment synchronous, especially given that thrown errors in that segment are not synchronous. That whole part of the spec is full of landmines. 😬