An async generator opens a database cursor before its first `yield` and closes it on the line after the yielding loop ends. If the consumer stops reading partway through, what actually runs inside the generator body, and how do you guarantee the cursor is closed?

## What "stopping early" does to the body An async generator suspended at `yield` is waiting to be resumed, and there are three ways to resume it. `next(v)` resumes normally, making the `yield` expression evaluate to `v`. `throw(e)` resumes with a *throw completion*, as if `throw e` sat at the yield point. `return(v)` resumes with a *return completion*, as if `return v` sat there. Early termination is the third case. When a `for await...of` loop exits by `break`, by `return`, or because the loop body threw, it calls the iterator's `return()` method if one exists. So the generator does not continue past the yield — it unwinds from it. That is why cleanup placed *after* the loop is unreachable: ```js async function* rows(open) { const cursor = await open(); for (;;) { const row = await cursor.next(); if (row === null) break; yield row; // consumer breaks -> unwinds from here } await cursor.close(); // never reached on early exit } ``` ## finally is the only reliable place A return completion unwinds through the body exactly like a `return` statement does, which means enclosing `finally` blocks run. Put acquisition before the `try` and release in the `finally`: ```js async function* rows(open) { const cursor = await open(); try { for (;;) { const row = await cursor.next(); if (row === null) break; yield row; } } finally { await cursor.close(); // normal end, early exit, and thrown error alike } } ``` This single block covers all three exits: the loop finishing, the consumer abandoning it, and an exception from the fetch or from the consumer's body. `await` is legal in that `finally` because the body is an async function body, so asynchronous release — closing a connection, flushing a buffer, releasing a lock — is expressible. In a sync generator you have no such option. ## The promise nobody awaits `return()` is asynchronous: it hands back a promise that settles once the body has finished unwinding, including any awaits inside `finally`. `for await...of` awaits that promise before the loop statement completes, so the cleanup is genuinely done before execution continues past the loop. A hand-written driver does not get that for free: ```js const it = rows(open); try { while (true) { const { value, done } = await it.next(); if (done || found(value)) break; } } finally { await it.return(); // you must do what for await...of does for you } ``` Skipping this is a common leak in code that drives the iterator manually to interleave other work. ## The failure mode with no remedy in the language If a consumer neither exhausts the generator nor calls `return()` — it just stops calling `next()` and lets the reference go — the body stays suspended at its yield forever and the `finally` block never runs. There is no finalizer, no destructor, and no garbage-collection hook that will run it: collecting the generator object reclaims memory, not the cursor it was holding. `FinalizationRegistry` exists but is explicitly not guaranteed to run, so it is not a cleanup mechanism. The practical consequences: never write a generator that holds an expensive, limited resource open across yields if you cannot trust every consumer to terminate it properly. Where you can, prefer designs that let the caller stop the producer explicitly — passing in an abort signal, or exposing an explicit close — so shutdown is a first-class path rather than an accident of iteration. ## Edge behaviour worth knowing A `yield` inside the `finally` block delays completion: the generator is honouring the return request but is still able to emit, so the return does not take effect until the finally block finishes. This is legal, occasionally useful for emitting a final summary, and easy to get wrong — most cleanup blocks should not yield. Also note that whatever the `finally` block throws replaces the outcome of the original exit, which can mask the real error. If release can plausibly fail, catch and log inside the `finally` rather than letting a close error bury the exception that caused the unwind.