When you trace a JavaScript program that mixes synchronous logs, setTimeout callbacks and promise reactions, which parts of the resulting output order are guaranteed by the language, and which are incidental to the runtime and unsafe to depend on in production code or tests?

## Why the distinction matters Tracing puzzles teach a real model, but they also teach a bad habit: treating every line of predicted output as a contract. Some of that output is guaranteed by the language and will hold on any conforming engine forever; some of it merely describes what one runtime did on one machine on one day. Production code and, above all, tests go wrong when the second kind is mistaken for the first. ## What is genuinely guaranteed **Run to completion.** Once a function starts, no queued callback can interleave with it. Every trace begins by finishing the synchronous work in source order, with no exceptions and no preemption. **The microtask checkpoint.** When the call stack empties, the microtask queue is drained *completely* before the next task is taken — and microtasks queued during the drain join that same drain. This is why a whole `.then` chain that settles synchronously completes before any timer callback, and why a promise reaction queued inside a callback beats a timer that was registered earlier. **FIFO within one queue.** Two reactions registered in order on the same settled promise run in that order. Two timers registered with the *same* delay fire in registration order. **Deferral is unconditional.** A `.then` callback never runs synchronously, even on an already-settled promise; an `await` always suspends, even on a plain value. You can rely on "not now" without knowing anything about the value. Those four facts are enough to justify every step of a well-formed puzzle. ## What is incidental **Timer delays.** `setTimeout(fn, d)` means *at least* `d` milliseconds, and only once the runtime gets round to it. Deeply nested timers are clamped to a floor, and hosts apply their own policies to timers in inactive contexts. Therefore: ```js setTimeout(a, 0); setTimeout(b, 1); ``` is **not** a reliable way to order `a` before `b`. It usually works. "Usually works" is the definition of a flaky test. **Cross-source ordering.** The relative order of a timer callback, a network completion and a dispatched event is decided by the host's scheduling, not by ECMAScript. A trace that says "the fetch handler runs before the second timer" is describing an observation, not a rule. **Tick counts across implementations.** Awaiting a native promise costs one microtask tick on current engines; awaiting a foreign *thenable* — any object with a `then` method, such as a third-party promise — costs at least one extra tick, because the engine must call that `then` from a job of its own. Code that depends on landing in a specific tick breaks the moment a dependency swaps its promise implementation. The same caution applies to any output you derived from a very old engine, where `await` cost three ticks rather than one. **Anything you measured rather than derived.** If you cannot name the rule that produces an ordering, treat it as incidental. ## The failure mode this prevents The classic bad test is: ```js triggerWork(); setTimeout(() => { expect(state.done).toBe(true); }, 0); ``` The author reasoned "a timer runs after the microtasks, so everything must have finished". It holds only while the work under test settles entirely within microtasks. The day someone inserts a real I/O round trip or a second timer, the assertion runs too early and the test fails intermittently — the most expensive kind of failure, because it looks like a flake rather than a bug. The fix is to wait on the thing itself: return or await the promise the work produces, or use whatever completion signal the API exposes, so the test's ordering assumption is the same as the code's. ## The same discipline in production code When two effects must happen in a particular order, express the dependency — await it, chain it, sequence it explicitly. Ordering that emerges from queue mechanics is invisible in the source, survives no refactor, and is impossible for a reviewer to verify. It is fine to *rely* on the microtask checkpoint deliberately, for example to batch a follow-up at the end of a unit of work; that is a documented guarantee. It is not fine to rely on a timer beating a promise chain. ## How to answer this in an interview Name the guarantees first and crisply, then name the incidentals with an example of each, then close on the practical rule: puzzles are for demonstrating the model, not for licensing code that depends on it. That progression shows you can both trace the machine and judge when the trace should not become a dependency.