lib: add a diagnostic channel for observing AsyncContextFrame.set

[szegedi]

Adds an async_context_frame.set diagnostic channel for observing AsyncContextFrame.set.

This is helpful for functionality in extensions written in C++ that need to keep some derived native state from one or more AsyncLocalStorages in sync with changes in active frame. It is possible that such an extension needs to use the state when it can not enter V8 to obtain the data through AsyncLocalStorage JS API. A subscriber to this diagnostic channel can be used instead to eagerly keep the native state updated.

[Qard]

You should also add the channel to the diagnostics_channel docs here: https://github.com/nodejs/node/blob/main/doc/api/diagnostics_channel.md?plain=1#L1104

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.23%. Comparing base (b197355) to head (1dc7cfd).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #58229   +/-   ##
=======================================
  Coverage   90.23%   90.23%           
=======================================
  Files         633      633           
  Lines      186818   186822    +4     
  Branches    36668    36667    -1     
=======================================
+ Hits       168578   168587    +9     
- Misses      11036    11040    +4     
+ Partials     7204     7195    -9     

Files with missing lines	Coverage Δ
lib/internal/async_context_frame.js	100.00% <100.00%> (ø)

... and 24 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.

[Qard]

Might also be a good idea to have the tests validate that the frame can be used to look up the state for a given store. The store is the key so it should just be frame.get(store) to get the value.

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[Flarna]

Should we expose/document the AsyncContextFrame class via public API?
With doing just this users get some undocumented, internal thing into their hand and all they can do is to guess what it is, which API it exposes.
Any internal change on AsyncContextFrame would be breaking for all users of this channel.

[szegedi]

I discussed this with @Qard; he thinks (but can of course speak for himself here 😁) that since all channels are by default experimental, we aren't promising stability in what's returned here. As far as I'm concerned, I would've been fine with not even exposing the parameter at all.

[Flarna]

One of the probles to never stabilize async_hooks was because it leaks internal.
We should avoid to add again experimental APIs leaking internal as they can't be stabilized.

If the frame is not needed it's likely best to remove it. Alternative could be to replace it by a well documented wrapper object exposing only parts of AsyncContextFrame or other data like the cause for the set,...

[Flarna]

Does this hold true for await?
As far as I remember await or more concrete for Promises the activation/setting happens by v8.

[szegedi]

No, an event won't be published on await continuation. If we were to implement that, we'd be right back to using Isolate::SetPromiseHook. Fortunately, it is not necessary. V8 appropriately propagates whatever is set as the Continuation Preserved Embedder Data (CPED) into the "then" callbacks. I was a bit vague when saying "native state is kept in sync with change in the active frame" but the idea really is that the derived native state itself should be stored in and retrieved from the AsyncContextFrame (ACF) object, e.g. by defining a private symbol-keyed property on it. This way when V8 changes current ACF as its CPED, the native state automatically tracks and we "only" need to observe when Node sets ACF in CPED for the current execution to ensure the native state in the current ACF object is up to date.
Unsurprisingly, I'm working on doing exactly this in the Datadog's profiler if you want to see a C++ example :-)

[Flarna]

Are you really interested in the set() calls?
If I understand this correct it's actually the creation of a new AsyncContextFrame - so the ALS.enterWith() and run() calls which are of your interest but not the ACF.exchange() calls.

exchange() is called by e.g. timers, nextTick,... - to mimic what v8 does automatically for promises.