fix(ext/napi): restore Explicit microtask policy in napi_resolve_deferred#35212
Merged
Merged
Conversation
…rred napi_resolve_deferred toggled the microtask policy to Explicit while resolving and then restored Auto. That restore predated the runtime switching to the Explicit microtask policy globally (#32466): because set_microtasks_policy acts on the whole isolate, resolving any deferred permanently flipped the runtime back to Auto. Under Auto, V8 auto-drains microtasks whenever the call stack unwinds to depth zero, including mid-construction inside napi_new_instance when it runs from native event-loop code. A drained microtask that constructs another napi-rs class while the factory is still in flight leaves an unwrapped instance behind, producing the intermittent "Failed to recover `TsconfigCache` type from napi value" failures (#33924) seen with rolldown/vite builds. Restore Explicit instead of Auto so the runtime keeps its intended policy. Synchronous JS re-entry from native constructors (e.g. zeromq's Object.seal) is unaffected.
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
napi_resolve_deferredswitches the microtask policy to Explicit whileresolving the promise and then restores it afterwards. That restore set
the policy back to Auto, which predated the runtime moving to the
Explicit microtask policy globally (#32466). Because
set_microtasks_policyacts on the whole isolate rather than a scope,resolving any deferred permanently flipped the entire runtime back to
Auto.
Under the Auto policy V8 auto-drains microtasks whenever the call stack
unwinds to depth zero, including mid-construction inside
napi_new_instancewhen it runs from native event-loop code such as anasync-work completion. If a drained microtask constructs another
napi-rs class while the factory is still in flight, napi-rs's
class-agnostic factory flag leaks across classes and leaves an unwrapped
instance behind. That is the intermittent "Failed to recover
TsconfigCachetype from napi value" failure seen in rolldown/vitebuilds. Restoring Explicit instead of Auto keeps the runtime's intended
policy; synchronous JS re-entry from native constructors (for example
zeromq's
Object.seal) is unaffected. The regression test recreates thedepth-zero context with async work and asserts the queued microtask does
not drain during construction.
Fixes #33924