A reviewer tells you to replace every `await` inside a loop with a `Promise.all` over the whole collection. When is that refactor wrong or dangerous, and how do you decide case by case?

## Independence is the precondition "`await` in a loop is a bug" is a useful heuristic and a bad rule. The transformation from a sequential loop to a concurrent batch is only sound when the iterations are independent of each other and the collection is small enough that starting all of it at once is acceptable. Both halves of that sentence fail in real code. ## Genuine data dependencies The clearest disqualifier is when iteration N's inputs come from iteration N-1's output. Pagination is the everyday example: ```js let cursor = undefined; const all = []; do { const page = await fetchPage(cursor); // cursor comes from the previous page all.push(...page.items); cursor = page.nextCursor; } while (cursor); ``` You cannot start page 2 before page 1 returns, because you do not yet know what to ask for. The same holds for redirect chains, tree or graph traversals where children are discovered as you go, and retry loops where the next attempt depends on the previous failure. Worth distinguishing: many *apparent* dependencies are accidental. If the loop only accumulates into an array, or reuses a variable for convenience, the iterations are independent and the accumulation can move after the batch. Read what the body actually consumes, not how it is written. ## Ordered side effects Even with independent inputs, the *effects* may need ordering. Appending lines to a file, applying a sequence of state transitions, emitting events a consumer expects in order, or writing rows whose downstream processing assumes insertion order — concurrency makes completion order nondeterministic, so any of these can silently corrupt results. `Promise.all` preserves the order of its *results array*, which is often mistaken for a guarantee about the order in which the operations ran. It is not: the calls interleave freely, and only the collected values are re-ordered to match the input. ## Scale and the accidental rate limit A loop over 20 items behaves very differently from the same loop over 20,000. Sequential execution imposes a concurrency of exactly one; replacing it with `Promise.all(items.map(...))` imposes a concurrency of `items.length`. If the collection comes from user input, a database query, or a file, that number is unbounded in practice. The observable failures are familiar: connection-pool exhaustion, ephemeral-port or file-descriptor limits, `429 Too Many Requests` from the dependency, memory spikes from thousands of in-flight response buffers, and a self-inflicted overload that takes the downstream service out for everyone. Crucially the answer here is neither the loop nor the unbounded batch — it is running a fixed number at a time, which is a distinct technique with its own tradeoffs. What matters at review time is recognising that "how many at once" is a decision the code must make explicitly once the collection is not small and fixed. ## Failure semantics change too The sequential loop stops at the first error: everything before it completed, everything after it never started. `Promise.all` rejects as soon as any input rejects, but the other operations are already running and are *not* cancelled — they will complete or fail in the background after your `catch` has run. For read-only work that difference is cosmetic. For writes it is not: after a failure you no longer know which subset was applied, so your recovery or cleanup logic must handle an indeterminate partial state, and any "undo what we did" path has to account for effects that landed after the rejection. ## A decision procedure For each awaited call in the loop, ask in order: 1. Does any argument, or any branch guarding the call, derive from a previous iteration's result? If yes, it must stay sequential. 2. Do the side effects have to land in a defined order? If yes, keep it sequential. 3. Is the collection size bounded and small — a handful of known keys, a fixed set of services? If yes, batch it with `Promise.all`. 4. Otherwise the size is unbounded: keep the work concurrent but capped, and pick the cap from the dependency's real limits, not from a round number. 5. If the operations all hit the same dependency, ask whether it offers a bulk endpoint. One request for 500 ids beats any client-side fan-out of 500 requests and removes the question entirely. ## What to say in the review The honest response to "use `Promise.all` everywhere" is that the loop encodes a claim — these steps are ordered — and the batch encodes a different one — these steps are independent and all may run at once. Whichever matches the domain is correct; the performance argument only applies once the independence claim is true.