Given `getUser().then(user => { saveUser(user); }).then(() => console.log('done'))`, where `saveUser` returns a promise, why does "done" print before the save finishes, and what is the fix?

## What the code actually does Split the chain into its two links. Link one is `.then(user => { saveUser(user); })`. When `getUser()`'s promise fulfils, this callback runs, calls `saveUser(user)` — which really does start the save and really does return a promise — and then discards it. A braced arrow body is a statement block: its value is `undefined` unless you write `return`. So the callback returns `undefined`. Link two therefore sees a fulfilled promise carrying `undefined` almost immediately, and logs `done`. Meanwhile the save is still running somewhere with nobody watching. ```js getUser() .then(user => { saveUser(user); }) // returns undefined .then(() => console.log('done')); // runs now, not after the save ``` ## The rule being violated A `.then` callback's return value is the entire interface to the next link. Return a plain value and the derived promise fulfils with it right away; return a promise or thenable and the derived promise **adopts** it, staying pending until it settles. Waiting is opt-in, and the opt-in is the word `return`. So the fix is to return the promise: ```js getUser() .then(user => saveUser(user)) // concise body: implicit return .then(() => console.log('done')); // now runs after the save ``` Equivalently, `user => { return saveUser(user); }`. If you also need the saved result later, return a promise that carries it — for example `user => saveUser(user).then(saved => ({ user, saved }))`. ## The second, nastier consequence Timing is the symptom people notice; the error handling is the bug that hurts in production. Because the chain never subscribed to the promise `saveUser` returned, that promise is **floating**. If the save rejects: - the chain's `.catch` never sees it — the chain already fulfilled with `undefined` and moved on; - no handler is ever attached, so the host reports an unhandled rejection (`unhandledrejection` in browsers, `unhandledRejection` in Node); - your request handler reports success while the write failed. That combination — a green log line and a silently lost write — is exactly why interviewers use this question. "Done" printing early is a scheduling curiosity; losing a rejection is a data-integrity incident. ## Why the mistake is so easy to make Three things conspire: **Arrow-body syntax.** `x => f(x)` and `x => { f(x); }` look nearly identical and behave completely differently. Adding a temporary `console.log` inside a concise-body arrow forces you to add braces, which silently deletes the return. **It looks like it works.** In the happy path with a fast local save, the process usually stays alive long enough for the write to land. The bug surfaces under load, in a serverless function that freezes after the response, or in a test that asserts on state right after `await`ing the chain. **`forEach` has the same shape.** `items.forEach(i => save(i))` starts every save and returns `undefined`; `forEach` ignores callback return values entirely, so nothing can await them. The fix there is a mapping into promises plus a combinator that waits for them. ## Diagnosing it When a chain "finishes too early", read every callback body and ask: does the last statement produce a promise, and does it leave the callback? Then check the value the next link receives — if it is `undefined` and you expected data, you have found it. Turning on an unhandled-rejection listener in development surfaces the floating promise directly, usually with a stack that points at the offending callback. ## The same rule in async functions The trap survives the syntax change. Inside an `async` function, `saveUser(user);` on its own line starts the work and moves on exactly like the braced arrow; `await saveUser(user);` or `return saveUser(user);` is what makes the caller wait. Anywhere a promise is produced, ask who is going to hold on to it — if the answer is nobody, you have a floating promise whether or not the code contains the word `then`.