[TheHypnoo]

A queued async-resource destroy is held until the enclosing execution scopes have emitted their after hook — but only for the resources those scopes own. drain_gc_destroy_queue retains the entries whose serial is still on the execution stack (plus those whose async job domain is not eligible yet) and delivers the rest, so ready resources unrelated to the active scope are not stuck behind it.

That fix landed directly on main as 9e1ec80e77 on 2026-10-18. It touches crates/, but no changelog.d/ fragment came with it, so the behavior never reached the release notes. This PR is that backfill: one fragment, no code change, no behavior change.

The same bug was carried as a PR, #11761, now closed as superseded: its version returned from drain_gc_destroy_queue whenever any scope was active, which also held back unrelated ready resources and made all destroy delivery depend on the execution stack always unwinding to empty. What is on main retains selectively instead, and pins the ordering with the node-suite case test-parity/node-suite/async_hooks/hooks/interval-cancel-checkpoint-lifecycle.ts (an interval clearing itself inside its own callback, observed from process.nextTick and queueMicrotask in that same scope).

No version bump: this is a changelog.d/-only change, matching how the previous fragment-numbering commits landed.

[coderabbitai]

Caution

Review failed

The pull request is closed.

Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}