In TypeScript, a handler writes `if (state.pending) { await flush(); state.pending.cancel(); }`, where `pending` is an optional property and `flush()` may clear it. Does the compiler complain about the access after the await, is its answer sound, and how would you write this safely?

## What actually invalidates narrowing Control-flow analysis tracks a narrowed reference until something it can see disturbs it. In practice that means an assignment, in the same function body, to that reference or to a prefix of it — `state.pending = ...` or `state = ...`. It also means a branch merge, where the type becomes the union of the incoming branches. That is the whole list the checker consults for a property path. What is *not* on the list: calling a function, awaiting a promise, yielding from a generator, or throwing and catching. None of those are assignments the checker can attribute to the reference, so a narrowed property stays narrowed straight through them. ```ts interface State { pending?: { cancel(): void } } async function stop(state: State, flush: () => Promise<void>) { if (state.pending) { await flush(); // may set state.pending = undefined state.pending.cancel(); // compiles — and may throw at runtime } } ``` ## Why this is deliberate The alternative would be to reset every narrowing at every call, since almost any function *could* mutate an object reachable from it. Under that rule, code like `if (user.profile) { log(user); user.profile.name }` would fail, and the fix would be to re-check after every call or to assert everywhere. The result would be worse code and more assertions, which is a net loss for safety. So the compiler makes a usability trade: it assumes calls do not mutate the objects you narrowed. This is one of TypeScript's well-known intentional unsoundnesses, in the same family as assertions and bivariant method parameters — places where the type system knowingly reports "fine" for something that can fail. Knowing where these live is exactly what a senior interview is probing. ## Why await makes it worse A plain call at least runs to completion before your next statement. An `await` suspends the function and lets the entire rest of the program run: other handlers, timers, socket events, a second invocation of this same handler. The window in which someone can clear `state.pending` is not a few instructions, it is unbounded. Anything you narrowed before an await, and any other invariant you checked before it, is a claim about the past by the time execution resumes. Note the contrast with the closure case. Inside a nested function the checker *does* drop the narrowing, because it cannot order the body at all. Across an await it keeps the narrowing, because the statements are still in one ordered body — even though the real-world risk is comparable. That asymmetry is worth being able to state plainly. ## Writing it safely There are two honest options, and they mean different things. Snapshot before the await: ```ts const pending = state.pending; if (pending) { await flush(); pending.cancel(); // the object we checked, whatever the state says now } ``` The const holds the object that existed at check time. `cancel()` is guaranteed to run on a real object. Whether cancelling a task that was already flushed is correct is a domain question you must answer — but there is no crash and no lie in the types. Re-read after the await: ```ts if (state.pending) { await flush(); state.pending?.cancel(); // current value, guarded again } ``` Here you accept that the field may have changed and handle the case. Use this when the field is the source of truth and a cleared field means "nothing to cancel". ## Structural defences Beyond the local fix, the durable answers reduce how often mutable narrowed state is read late: - Destructure inputs into locals at the top of the function, so guards apply to immutable bindings. - Model lifecycle state as a discriminated union that is replaced wholesale (`{ status: "idle" } | { status: "running"; task: Task }`) rather than as a bag of optional fields flipped in place; a replaced object cannot be half-updated under you. - Keep awaits out of the middle of narrowed blocks — do the async work first, then check, then act. - In review, treat "narrowed property read after an await" as a smell worth a second look, since the compiler will never flag it. ## The interview answer in one line The compiler is silent because calls and awaits are not assignments; the silence is a designed trade-over-soundness; and the code is only safe if you snapshot the value or re-check it yourself.