A callback passed to `setTimeout` throws, and the stack trace contains no frames from the function that scheduled it. Why does that happen in JavaScript, and how do you preserve the calling context?

## Why the frames are gone A stack trace is not a history of the program — it is a snapshot of the frames that are live at one instant. JavaScript's execution model makes that decisive: the engine runs the current job to completion, and only when the call stack is empty does it pick up the next scheduled task. ```js function schedule() { setTimeout(() => { throw new Error('boom'); }, 0); } schedule(); ``` By the time the arrow function runs, `schedule` has returned and its frame is gone. The callback is invoked from an empty stack, so the trace reads roughly: ``` Error: boom at Timeout._onTimeout (/app/a.js:3:11) ...runtime internals... ``` Nothing about `schedule` survives, because nothing about `schedule` still exists. This is not a bug or a missing feature — it falls directly out of run-to-completion plus "capture happens at construction". ## What the engine does stitch, and what it does not Modern V8 implements async stack traces: when an async function `await`s a promise, the engine keeps enough information to splice the awaiting frames back into a trace produced later in the continuation. So this generally *does* give a useful trace naming both functions: ```js async function outer() { await inner(); } async function inner() { throw new Error('boom'); } ``` The limits are the interesting part. The stitching applies to awaited promises within async functions. It does not extend to: - a plain function handed to `setTimeout` or `setInterval`; - a listener registered on an event emitter and invoked much later; - a callback passed into a promise executor and stored for later; - a callback-style API that never became a promise at all. In every one of those, the scheduling frames were unwound before the callback ran, and no continuation relationship was recorded. Rewriting a callback chain into `async`/`await` is therefore not only a readability change: it hands the engine the information it needs to produce a joined trace. ## Preserving context yourself The general technique is to capture the context while it still exists and carry it forward as data. ```js function schedule(work, ms) { const scheduledAt = new Error('scheduled here'); // captured NOW setTimeout(() => { try { work(); } catch (e) { throw new Error(`scheduled work failed: ${e.message}`, { cause: e, }); } }, ms); return scheduledAt; } ``` Two variants are worth distinguishing. Attaching the *caught* error as `cause` links the failure to its own construction site — useful, but it does not recover the scheduler's frames. To recover those you must close over the pre-built `scheduledAt` error and surface its `stack` alongside the failure, because that object is the only remaining record of a stack that no longer exists. A wrapper that logs both strings gives a reader the full picture: where the work was queued, and where it blew up. The cost is why this is not on by default. Constructing an error captures frames, and doing it on every scheduled unit of work in a hot loop is measurable. Real systems apply it selectively: at the few boundaries where async work is dispatched, not at every call site. ## Diagnosing when the trace is thin When a production trace looks truncated, work through the causes in order: 1. **Frame limit.** V8 captures at most `Error.stackTraceLimit` frames, default 10. Deep framework chains hit this. Raise it temporarily while investigating. 2. **Async boundary.** The trace starts at a callback with runtime internals beneath it — the signature of the loss described above. 3. **Late construction.** The error was created in a generic handler rather than at the failure point, so it faithfully reports a place you do not care about. Construct errors where the failure is detected. 4. **Rethrown wrapper without a cause.** Someone caught, discarded, and threw a fresh error; the inner frames were never linked. Wrapping with `{ cause }` is the fix. ## The judgment an interviewer is listening for A strong answer separates the mechanism from the workaround. The mechanism is that stacks are frame snapshots and asynchronous work runs on a stack that no longer contains its scheduler. The workaround is to move the context out of the stack and into the heap — a captured error object, a request identifier threaded through, a correlation id in the log line. A weaker answer reaches straight for "turn on async stack traces" as if it were a switch that recovers everything; it recovers awaited promise chains and nothing else.