Skip to content

test: async context for thrown microtasks - #64147

Open
mcollina wants to merge 2 commits into
nodejs:mainfrom
mcollina:fix-microtask-async-context-frame
Open

test: async context for thrown microtasks#64147
mcollina wants to merge 2 commits into
nodejs:mainfrom
mcollina:fix-microtask-async-context-frame

Conversation

@mcollina

@mcollina mcollina commented Jun 26, 2026

Copy link
Copy Markdown
Member

Documents the current AsyncLocalStorage behavior when a microtask throws: the throwing microtask's context frame remains current while the exception is being reported, so the uncaughtException handler, exception formatting, and microtasks queued during formatting all observe it.

Adds a regression test covering this behavior with a non-Error object thrown from a microtask whose string conversion queues another microtask.

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. process Issues and PRs related to the process subsystem. labels Jun 26, 2026
@mcollina

Copy link
Copy Markdown
Member Author

cc @nodejs/diagnostics

@Qard Qard left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we generally want the context to be available in uncaughtException? We did a bunch of work at one point to ensure it would be there so uncaughtException handlers could attribute the errors to spans they came from in tracers. It'd probably be more correct to cut off the context after those handlers run. 🤔

@mcollina

Copy link
Copy Markdown
Member Author

Don't we generally want the context to be available in uncaughtException?

I thought as well.

The key assertion here is this one: https://github.com/nodejs/node/pull/64147/changes#diff-6c14bb576b8a1eaf12aeb421aec5efd35b58d92c8a02d668a83a2f74f9c6474fR18.

@mcollina

Copy link
Copy Markdown
Member Author

Note that if we think the current behavior is correct, then I'll add a test for it to match.

@ronag ronag added request-ci Add this label to start a Jenkins CI on a PR. author ready PRs that have at least one approval, no outstanding review comments, and a CI started. labels Aug 6, 2026
@github-actions github-actions Bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Aug 6, 2026
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@trivikr

trivikr commented Aug 9, 2026

Copy link
Copy Markdown
Member

@mcollina The commit needs to be signed.

Signed-off-by: Matteo Collina <hello@matteocollina.com>
@mcollina
mcollina force-pushed the fix-microtask-async-context-frame branch from f091a7a to f2da5c5 Compare August 10, 2026 08:10
@codecov

codecov Bot commented Aug 10, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (65a0265) to head (e846ea8).
⚠️ Report is 277 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #64147      +/-   ##
==========================================
- Coverage   90.32%   90.14%   -0.19%     
==========================================
  Files         759      751       -8     
  Lines      248342   253648    +5306     
  Branches    46866    47774     +908     
==========================================
+ Hits       224320   228648    +4328     
- Misses      15461    16252     +791     
- Partials     8561     8748     +187     

see 226 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.

@mcollina

Copy link
Copy Markdown
Member Author

@trivikr PTAL

@legendecas legendecas removed the author ready PRs that have at least one approval, no outstanding review comments, and a CI started. label Aug 14, 2026
@legendecas

Copy link
Copy Markdown
Member

I agree the behavior as described by @Qard at #64147 (review) is expected, that an uncaughtException could observe the context where it's uncaught. Could we add a test on the current behavior instead?

assert.strictEqual(asyncLocalStorage.getStore(), undefined);
}));

asyncLocalStorage.run(sensitive, () => {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test illustrates a secretive AsyncLocalStorage store. But to actually expose an AsyncLocalStorage value, it has to be exported programmatically, i.e. either export the AsyncLocalStorage instance, or export a value getter. So I don't find this context being available at uncaughtException problematic.

@legendecas legendecas added the async_local_storage AsyncLocalStorage label Aug 14, 2026
The AsyncLocalStorage context of a throwing microtask remains current
while the exception is being reported: the uncaughtException handler,
exception formatting, and microtasks queued during formatting all
observe it. Add a regression test documenting this current behavior.

Signed-off-by: Matteo Collina <hello@matteocollina.com>
@mcollina mcollina changed the title async_hooks: clear context frame for thrown microtasks test: async context for thrown microtasks Aug 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

async_local_storage AsyncLocalStorage needs-ci PRs that need a full CI run. process Issues and PRs related to the process subsystem.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants