When execution inside an `async` function reaches its first `await`, what does the caller of that function receive at that moment, and is anything blocked while the awaited value is still pending?

## Three phases of one call Calling an async function has three distinct phases, and mixing them up is the source of most confusion. 1. **Synchronous prefix.** The moment you call it, the body starts executing immediately, on the caller's stack, exactly like a normal function. Everything before the first `await` — argument validation, logging, kicking off a request — has already happened by the time the call expression evaluates. 2. **Suspension.** At the first `await`, the frame is parked. Control returns to the caller, which gets the pending promise that was created before the body started. 3. **Resumption.** Once the awaited value has settled, the frame is restored and execution continues on the line after the `await`, with all locals exactly as they were. Further awaits repeat phases 2 and 3. ```js function compute() { return Promise.resolve(21); } async function work() { console.log('A'); // phase 1: runs on the call const v = await compute(); // phase 2: suspends here console.log('C', v); // phase 3: resumes here return v * 2; } const p = work(); // logs 'A' console.log('B', p); // logs 'B' Promise { <pending> } p.then(x => console.log('D', x)); // A, B Promise { <pending> }, C 21, D 42 ``` ## Suspending is not blocking Blocking would mean the thread stops and does nothing until a result arrives — no other function runs, no other queued work is processed. That is not what happens. `await` removes *this function* from the stack and leaves the thread free. The caller's remaining statements run, other pending work runs, and in a browser the page keeps responding. The distinction has a sharp practical consequence: `await` cannot rescue you from slow **synchronous** code. A tight loop burning 400 ms inside an async function still occupies the thread for 400 ms, awaits or no awaits, because there is no suspension point inside it. Async functions give up the thread only at an `await`. ## The caller always gets the promise, never the value The returned promise exists before the body starts, so the caller receives it at the first suspension (or when the body finishes, if there is no await). It is pending until the function completes. A caller that logs the call result without awaiting sees `Promise { <pending> }` — the single most common beginner bug, and the reason async-ness is "contagious": to get a value, the caller must itself await, which means the caller must itself be async or must use `.then`. ## What survives the suspension The frame keeps everything: local `const`/`let` bindings, the parameter values, the `this` binding, closed-over variables, and the position inside any surrounding loop or `try` block. That is why you can write sequential-looking code that stops and starts, and why an object captured in a local variable stays reachable — and therefore not collectable — for the whole time the function is suspended. A long-lived suspended frame that holds a large buffer keeps that buffer alive. ## Resumption is scheduled, not immediate When the awaited value settles, the function does not resume inside the settling code. The continuation is queued as a job and runs later, once the currently executing code has finished. That is what guarantees the run-to-completion property: no other code interleaves halfway through a statement. The precise queue mechanics and the tick on which the resumption lands belong to the event loop rather than to the async-function sugar; what you must be able to state here is that resumption is always deferred, never synchronous — even if the awaited promise is already settled. ## Awaiting the same promise twice, and awaiting nothing Suspension happens per `await`, not per promise. Two awaits of the same already-settled promise suspend twice. And because suspension is unconditional, even `await` on a non-promise value defers the rest of the function. There is no fast path that keeps you on the current stack. ## How interviewers probe it Typically: "does `await` block the thread?", "what does the caller see while it is waiting?", or "why is my UI still frozen when everything is async?". A strong answer names the three phases, uses the word *suspend* rather than *wait*, and points out that only awaits yield — synchronous work never does.