Async mistakes that bite

Six mistakes follow, and they look unrelated until you notice they are all the same error: treating a promise as though it were the value inside it, or assuming something waited when nothing did.

None of them is a syntax error. That is what makes them expensive. The program runs, the console stays quiet, and the wrong thing happens somewhere far from the line that caused it.

Read this lesson as a checklist you can run over your own code, not as trivia. Each section names the symptom first, because the symptom is what you will actually meet.

Symptom: a variable holds `[object Promise]`, or a property of it is `undefined`, or arithmetic on it produces `NaN`, or `if (thing)` is true when it should be false.

Cause: you called an async function without awaiting it, so you are holding the promise rather than its value. Because a promise is an object, every one of those operations quietly does something instead of failing loudly. Every object is truthy, so `if (user)` is true even when the user does not exist. Adding a number to it concatenates onto "[object Promise]". Comparing it with `>` gives `false`, because the comparison ends up with `NaN`.

Fix: `await` it, or return it and let the caller await. The habit that prevents it is to know which of your own functions are async — a naming convention helps, and a linter rule for floating promises helps more.

Symptom: a loop that is supposed to process items one at a time finishes instantly, and the totals afterwards are empty or wrong.

Cause: `array.forEach(async (item) => { await work(item); })` looks like a loop with waiting in it, but the async callback returns a promise and `forEach` throws that return value away. MDN states it directly: `forEach` expects a synchronous function and does not wait for promises. Every iteration starts, none is waited for, and `forEach` returns `undefined` before any of them finish.

Fix, when order matters or you want one at a time: `for (const item of items) { await work(item); }`. A `for...of` loop sits inside your async function, so `await` genuinely pauses it.

Fix, when they can all run at once: `await Promise.all(items.map(work))`. `map` keeps the returned promises instead of discarding them, and `Promise.all` waits for the lot.

This one is worth checking for by eye whenever you see `async` immediately after `forEach(`. The same trap applies to `map` without a `Promise.all` around it — you get an array of promises, which is at least a visible symptom.

Symptom: an unhandled rejection appears in the console even though the call is plainly inside a `try` block.

Cause: `try { work(); } catch (error) { ... }` where `work` is async. The `try` block finishes the instant `work` returns its promise, long before that promise rejects. By the time the failure exists, this `try` is over — and a rejection is not a thrown exception, so it was never a candidate for that `catch` anyway.

Fix: `try { await work(); } catch (error) { ... }`. The `await` is what turns the rejection into a real exception at a moment when the `try` block is still active.

The subtler cousin is `return work();` inside a `try`. The promise leaves the function before it settles, so this function's `catch` never sees the failure — it surfaces in the caller instead. `return await work();` keeps the waiting inside the `try`.

Symptom: "UnhandledPromiseRejection" in the console, or in Node a process that exits with a non-zero code for no obvious reason.

Cause: a promise was created and nothing ever attached a handler or awaited it. MDN calls this a floating promise, and the classic version is a `.then` handler that starts work without returning it: `.then((url) => { fetch(url); })`. The inner promise is dropped on the floor, so nothing waits for it and nothing catches it.

Fix: every promise you create should end up awaited, returned, or explicitly handled with `.catch`. "Fire and forget" is a legitimate choice occasionally, but it should be written down — `void doThing().catch(reportError)` says you meant it.

Do not silence it with an empty `catch`. `catch (error) {}` converts a loud failure into a silent one, which is strictly worse than the crash: the program carries on with bad data and the trail is gone.

Symptom: something that should take a second takes a minute, and the network panel shows requests going out one after another in a neat staircase.

Cause: `for (const id of ids) { results.push(await loadOne(id)); }` where the fifty loads have nothing to do with each other. Each iteration waits for the previous one for no reason at all.

Fix: `const results = await Promise.all(ids.map(loadOne));` — start them all, wait once.

And the important counterweight: this is not always a bug. Awaiting in a loop is correct when each step needs the previous result, when a rate limit forbids parallel calls, or when firing hundreds of requests at once would overwhelm the server. Then it is a deliberate decision, and it is worth a one-line comment saying so — otherwise the next reader will "fix" it.

Symptom: errors are caught in one path and escape in another, and nobody can say why by reading the function.

Cause: half the function uses `await` inside a `try`/`catch` and half uses `.then(...).catch(...)`. The two are compatible — an async function returns a promise and `await` accepts one — but the error paths are now in two different places, and it is easy to leave a `.then` branch with no `.catch` at all.

Fix: pick one style per function. Use `await` in code you are writing; use `.then` when you are handing a handler to somebody else's API. Do not alternate line by line.

Before you call an asynchronous function finished, run these five questions over it. Is every call to an async function awaited, returned, or deliberately handled with `.catch`? Is every `await` inside a `try` that is still open when the promise settles? Does any `forEach` contain an `async` callback? Does any `await` sit inside a loop where the iterations are independent? And can I say, for each promise this function creates, who is listening when it fails?

Every one of those questions is answerable by reading, without running anything. That is the point: these bugs do not announce themselves at runtime, so the check has to happen at reading time.