Hi Eric, Thanks for reaching out, and for the very detailed analysis. I think you haven't seen much interaction on the bug because of a combination of August holidays, bystander syndrome, and general complexity of all the promise stuff.
It sounds like you've found a bug in our C++ implementation which is incompatible with the spec; I'd have to read into the exact details but it sounds plausible. This is great, and we should fix this, however your subsequent comments sound like they want the broken behaviour? In general, for us, spec is non-negotiable (the few times we do break spec is for web compatibility or some serious performance concern), so if you think a break from spec behaviour would be useful for Node, then you'd want to make that a spec proposal. The nested microtask queues Node is using sound a bit broken, since it sounds like the microtask queue is only drained once? If I understand the issue correctly, then the right fix would be for Node to always drain the inner microtask queue after something executes in the inner realm, or, I guess, patch the native context after draining it to refer to the outer microtask queue. - Leszek On Fri, Sep 5, 2025 at 3:31 PM Eric Rannaud <[email protected]> wrote: > Hi, > > I was hoping to get a discussion started on issue > https://issues.chromium.org/issues/441679231 that manifests itself in > Node when multiple microtask queues are in use (by package node:vm). > > In a nutshell, there are a couple of questions for V8 developers: > > - Currently, the C++ and Torque code paths for promise resolutions are > subtly different. I believe the Torque code is more in line with the spec. > > - However, to solve the issue faced by Node, the C++ code is actually > closer to what we need, I think. After evaluating an inner SourceTextModule > with its own microtask queue, the execution control flow can get "lost" > when returning to the surrounding context with a different microtask queue. > At issue is the logic to pick the context associated with the resolution, > where the thenable job task will be enqueued, and the shortcut taken by the > implementations to avoid the "then" property lookup when the promise > object is "native". > > There are more details and a proposed patch in the issue tracker, linked > above. > > Thanks, > Eric > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/v8-dev/e87cecc7-bcf3-4898-a5fc-4d991bc8b632n%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/e87cecc7-bcf3-4898-a5fc-4d991bc8b632n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAGxd1t-RMhyVFbsoTCbrmYvhP%2B2UB4VFS0VJZaYCX5-3YA7CvA%40mail.gmail.com.
