diagnostics_channel: replace using with try-finally

[ayush23chaudhary]

Fixes: #64230

Description

This PR replaces instances of the experimental using syntax with try...finally blocks inside lib/diagnostics_channel.js.

Since Explicit Resource Management is still a flagged feature in V8, encountering using in core causes a segfault when running Node with the --no-js-explicit-resource-management flag. This refactor maintains the exact same resource cleanup semantics by manually calling [SymbolDispose]() in a finally block, avoiding the flagged syntax entirely.

Example of Refactor

Before:

usingscope=this.withStoreScope(data);returnReflectApply(fn,thisArg,args);

After

constscope=this.withStoreScope(data);try{returnReflectApply(fn,thisArg,args);}finally{scope[SymbolDispose]();}

[Copilot]

Pull request overview

This PR removes the experimental using syntax from lib/diagnostics_channel.js, replacing it with equivalent try...finally disposal to avoid crashes when Node is run with --no-js-explicit-resource-management.

Changes:

• Replaced using statements with explicit try...finally blocks that invoke [SymbolDispose]().
• Updated scope handling in ActiveChannel, BoundedChannel, and TracingChannel paths to ensure disposal occurs reliably without relying on flagged syntax.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[anonrig]

Please add at least a test

[ayush23chaudhary]

Thanks for the thorough review, @Renegade334 and @anonrig!

1. I've updated RunStoresScope to perfectly match the suggested error handling and disposal order (NodeAggregateError).

2. I've added a test in test/parallel/test-diagnostics-channel-no-erm.js to ensure Node does not segfault when run with --no-js-explicit-resource-management.

3. I squashed everything into a single commit to resolve the commit linter failure.

[Renegade334]

Thanks for your changes! Some more comments 👍

[ayush23chaudhary]

@Renegade334!

1. I completely flattened the nested try...finally blocks in traceSync, tracePromise, and traceCallback.

2. I removed the empty try...finally blocks around the continuation window disposals.

3. I updated the test script to use the // Flags: directive, completely removing the spawnSync boilerplate

4. As noted, I also reverted RunStoresScope back to the simpler reverse-loop without the synchronous error logic

[Renegade334]

LGTM, but please run git commit --amend --no-edit --signoff to indicate acceptance of the Developer's Certificate of Origin, and make lint-js-fix to satisfy the linter.

[ayush23chaudhary]

Thanks for the LGTM!

I ran make lint-js-fix to resolve the formatting, and squashed/amended with --signoff to accept the DCO. Everything should be green and good to go

[Qard]

One minor nit but otherwise LGTM.

[nodejs-github-bot]

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

[jasnell]

I'm -1 on moving away from using. It's stage 4 at this point. I'd rather we forbid the option that allows it to be turned off than not use it.

[ayush23chaudhary]

Hi @jasnell, thanks for commenting

Since @Renegade334, @anonrig, and @Qard previously reviewed and approved this try-finally refactor to resolve #64230, it seems like there is a difference in philosophy on how Node core should handle the --no-js-explicit-resource-management flag now that ERM is Stage 4.

I am more than happy to pivot and take a different approach (like opening a PR to forbid the flag instead, if that is the preferred direction). I will pause my work here and let you all reach a consensus on the best path forward for the project.

Just let me know what the final decision is, and I'll be happy to execute it.

[Qard]

I'm fine either way. There's not much use of ERM in core yet, only exposing as an API surface. In my opinion, needing to use the try/finally form is not much more than a minor annoyance.

An argument could be made that no longer functioning with that flag should make the introduction of ERM use a semver-major. We could allow this change and then follow up with restoring ERM and calling it a semver-major. 🤔

[jasnell]

Given that the flag is a v8 flag and we intentionally do not cover v8 flags with semver, I'd argue that it doesn't need to be a semver-major at all.

[Renegade334]

@jasnell would you be happy to apply #64231 (comment) here?

Still disagree but won't block

[nodejs-github-bot]

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

[anonrig]

I don't think we should do this. I agree with other comments.

[Renegade334]

Since we have two linked PRs in parallel, cross-posting from #64231 (comment):

Forbidding that syntax at least until Node.js 24 is in maintenance mode is really the only way forward for backporters sake! I hope this can move forward

@anonrig would this be something on which you would reconsider your block?

Dismissing for the benefit of Node.js

[codecov]

Codecov Report

❌ Patch coverage is 98.38710% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.14%. Comparing base (42fd49a) to head (26f975d).
⚠️ Report is 972 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/diagnostics_channel.js	98.38%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64251 +/- ##
==========================================
- Coverage 92.02% 90.14% -1.89% 
==========================================
Files 381 769 +388 Lines 168990 261683 +92693 Branches 25901 49680 +23779 ==========================================
+ Hits 155521 235889 +80368 - Misses 13179 16803 +3624 - Partials 290 8991 +8701 

Files with missing lines	Coverage Δ
lib/diagnostics_channel.js	97.62% <98.38%> (+7.10%)	⬆️

... and 626 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/76310/

Stale

[ayush23chaudhary]

Hey @Renegade334. I just pushed a minor fixup to resolve a missing newline linter error, which invalidated the CI run you just started. Could you re-trigger it when you get a chance?