Inside an async function, what is the difference between `return somePromise` and `return await somePromise`, and in which situation does the choice actually change observable behaviour?

## Same value, different frame lifetime Both forms produce the same settled value, because settling with a thenable triggers adoption: ```js async function a() { return Promise.resolve(1); } async function b() { return await Promise.resolve(1); } // a() and b() both fulfil with 1 — never with a promise ``` What differs is *when the function's own frame goes away*. `return p` completes the function immediately; the returned promise's fate is delegated to `p`, and the frame is gone. `return await p` keeps the frame alive and suspended until `p` settles, and only then returns. ## The case that actually matters: inside try ```js async function withoutAwait() { try { return Promise.reject(new Error('boom')); } catch { return 'caught'; } } async function withAwait() { try { return await Promise.reject(new Error('boom')); } catch { return 'caught'; } } withoutAwait().then( v => console.log('a fulfilled', v), e => console.log('a rejected:', e.message) // a rejected: boom ); withAwait().then(v => console.log('b fulfilled', v)); // b fulfilled caught ``` In `withoutAwait` the function has already returned by the time the promise rejects, so control is no longer anywhere near the `catch`; the rejection flows straight out to the caller. In `withAwait` the rejection is delivered *into* the suspended frame as a throw at the `await`, still lexically inside the `try`, so the local handler runs. This is exactly the bug behind "my try/catch does not catch anything, and I do have an await somewhere in the function". ## finally timing The same frame-lifetime rule governs cleanup ordering: ```js const slow = new Promise(r => setTimeout(() => r('value'), 50)); async function eager() { try { return slow; } finally { console.log('cleanup ran'); } // logs immediately } async function patient() { try { return await slow; } finally { console.log('cleanup ran'); } // logs after 50 ms } ``` If the `finally` releases something the pending operation still needs — a connection, a lock, a temporary file, an abort controller — the eager form releases it while the work is still in flight. That is a real production defect, not a style question. ## Stack traces V8 reconstructs async stack traces from the chain of suspended frames. `return await p` leaves this function on that chain, so a rejection originating deep inside `p` reports a trace that includes your function. `return p` removes the frame first, and the trace typically loses that hop. On a large codebase this is the difference between a stack that names the failing operation and one that stops at a generic helper. ## Cost, and the lint history `return await` does add internal scheduling steps compared with plain `return`, since the value is unwrapped once for the await and the result then resolves the outer promise. In practice that cost is negligible next to the I/O being awaited. Older style guidance — the `no-return-await` lint rule — treated `return await` as pure redundancy; that advice has since been walked back precisely because of the try-block and stack-trace behaviour, and the rule was deprecated. ## A usable rule of thumb - Inside `try`/`catch`/`finally`, or anywhere the surrounding block owns a resource: **use `return await`**, so the function stays put until the work is done. - In a plain tail position with no surrounding block and no interest in stack quality: `return p` is fine and marginally leaner. - Never justify `return await` by claiming it prevents a nested promise. It does not, because that nesting never existed. ## What interviewers listen for A weak answer says one form is always redundant. A strong answer separates the *value* (identical) from the *frame lifetime* (different), then names the two observable consequences — local catch and finally ordering — and the diagnostic one, stack traces.