You call `.next()` on an async generator a second time before the promise from the first `.next()` has settled. What does the async generator do with that second call, and what does that imply about prefetching the next item?

## The request queue An async generator is not just a sync generator with promises bolted on. Each one maintains an internal queue of outstanding requests — one entry per `next()`, `return()`, or `throw()` call that has not yet been answered. When a request arrives: - if the generator is idle, it is resumed with that request immediately; - if the generator is already executing (suspended at an `await` inside its body, mid-resumption), the request is appended to the queue and the caller gets a promise that settles later. When the current resumption produces a result, that result settles the front request's promise, and the generator picks up the next queued request, if any. The consequence is that the body is **never** resumed reentrantly, and results are delivered in the order the calls were made. ```js async function* slow() { yield await new Promise((r) => setTimeout(() => r("a"), 50)); yield await new Promise((r) => setTimeout(() => r("b"), 50)); } const it = slow(); const p1 = it.next(); const p2 = it.next(); // queued, not concurrent Promise.all([p1, p2]).then(([x, y]) => console.log(x.value, y.value)); // a b, ~100ms ``` Two calls issued at the same instant still take the sum of both waits, not the max. There is no error and no warning — just no parallelism. ## Why the protocol is built that way A generator body has one program counter and one set of local variables. Resuming it twice at once would mean two logical executions sharing a single mutable frame — incoherent for any body with state, which is nearly all of them. Serialising requests is what lets you write the body as ordinary sequential code, with loops and locals and `try`/`finally`, and reason about it the same way you reason about an async function. It is also what gives pull-based iteration its natural pacing: the producer advances only when someone asks, so it cannot outrun the consumer or build up an unbounded internal buffer. That is a property, not an accident. ## Getting look-ahead where you actually want it Since the consumer cannot force overlap, the producer must express it. The standard trick is to start the request for the next item *before* handing out the current one: ```js const fetchPage = async (n) => `page${n}`; async function* prefetched() { let pending = fetchPage(0); for (let n = 1; n < 3; n++) { const current = await pending; pending = fetchPage(n); // in flight while the consumer works on `current` yield current; } yield await pending; } ``` Now the network request for page N+1 overlaps the consumer's processing of page N, cutting the wall-clock time of a sequential drain roughly in half when fetch and processing costs are comparable. Note what this costs: the generator now performs one request the consumer may never ask for, so if the consumer breaks early you have paid for an extra fetch — and, more seriously, that in-flight promise must not be left unobserved on an early exit, or a rejection from it becomes an unhandled rejection. A `finally` that awaits and swallows the outstanding promise handles that. For deeper look-ahead — keep k items buffered ahead of the consumer — the honest answer is that this is no longer the generator's job. You wrap it: a separate component drains the source generator into a bounded buffer and exposes its own async iterable, refilling as the consumer drains. That wrapper, not the protocol, is where the buffer bound and the extra-work-on-abandon policy live. ## What this rules out A few patterns people reach for and should not: - Calling `next()` in a loop without awaiting, expecting concurrent production. You get a queue, and if the generator is infinite you get an unbounded queue of pending promises. - Sharing one async generator between two consumers that both pull. They will interleave arbitrarily depending on who calls first; each item goes to exactly one of them. If you need fan-out, tee the sequence explicitly. - Using `Promise.all` over several `next()` calls to "parallelise" a single generator. It parallelises nothing; it only waits for a batch of sequential results. When the work genuinely is parallel — N independent URLs with no ordering dependency — a generator is the wrong producer shape for the fetching itself. Fetch concurrently with an explicit concurrency limit and use the generator, if at all, to deliver results as they land.