The key output order is promise -> timer -> nested timer. The promise runs first, but its new timer is queued behind the timer that already exists.
Console output or cleanup runs in an order that does not match the source code order. This shows up in promise-based setup that schedules fallback timers.
Thinking code created earlier in source always runs earlier.
Make ordering explicit instead of relying on when a queued callback might happen to run.
Promise.resolve().then(handleMicrotask); setTimeout(handleTimer, 0); // Assert/expect the microtask before the timer.
The console lane proves the visible order: promise -> timer -> nested timer. The active line and queues show why source order changed.
Add temporary logs around the sync line, promise callback, and timer, then confirm the order without adding arbitrary delays.
Related cases
Continue with nearby confusion while the mental model is fresh.
Sync execution
Most setup code, imports, and simple calculations behave this way.
setTimeout 0
Useful when you need to defer UI work until after the current event handler.
Promise before timeout
Promise-based state updates can happen before scheduled timers and animation cleanup.
Was this clear?
This stays local for now. It helps you track where the product still needs sharper cases.