Async Error-Handling Anti-Patterns — Find the Bug¶

Category: Async Anti-Patterns → Error Handling — errors that fall on the floor instead of propagating. Covers (collectively): Swallowed Promise Rejection · Floating Promise · Fire and Forget (Without Logging) · Forgotten await

This file is critical-reading practice. Each snippet below is a plausible chunk of real-world async code — mostly JavaScript/TypeScript, some Python asyncio. Your job is to read it the way a careful reviewer does and answer three questions:

What's the async bug? What's the user-visible impact? How do you fix it?

These are error-handling anti-patterns, so the failure rarely looks like a crash on line one. It looks like code that returns successfully while the work it promised never finished, or finished and failed with nobody listening. A forgotten await turns a Promise<User> into a truthy object and silently defeats an authorization check. A missing .catch() turns a failed database write into a process-wide unhandled rejection — or worse, into silent data loss. A fire-and-forget audit log that throws disappears without a trace. The compiler is happy; the linter (if you don't have the right rule on) is happy; production is not.

How to use this file: read each snippet and write your own answer before expanding the collapsible. The skill you're training is noticing that the function returned but the work didn't happen — not recalling the anti-pattern's name. One snippet is a deliberate trap: code that looks like a floating promise but is correctly fire-and-forget. Don't get fooled into "fixing" it.

A quick mental model you'll use repeatedly below:

• An async function always returns a Promise, even for if (x) style checks. A Promise object is always truthy — so if (somePromise) is if (true).
• A rejected Promise with no .catch() (and no await inside a try) becomes an unhandled rejection. In Node ≥15 that crashes the process by default; in browsers it fires unhandledrejection; in either case the originating request usually already returned "200 OK."
• Promise.all is fail-fast: the first rejection rejects the whole thing, and the other promises keep running with their results (and their errors) discarded.
• [].forEach(async ...) ignores the returned promises entirely — the loop finishes before any iteration's await resolves.

Table of Contents¶

1. The admin check that always passes
2. The save that reports success
3. The welcome email nobody sent
4. The handler that crashes the server later
5. Loading the dashboard, all or nothing
6. Deleting the files one by one
7. The Python audit log that ran nowhere
8. The price check that trusts a Promise
9. The retry that swallowed its own failure
10. The cache warmer that looks reckless
11. The Python gather that lost a writer
12. The total that was never summed
13. The two-step checkout
14. The metrics flush on shutdown

Snippet 1 — The admin check that always passes¶

// TypeScript — Express route guard for an admin-only endpoint
async function getUser(id: string): Promise<User> {
  const row = await db.query("SELECT * FROM users WHERE id = $1", [id]);
  return mapUser(row);
}

export function requireAdmin(req: Request, res: Response, next: NextFunction) {
  const user = getUser(req.session.userId);   // note: no await
  if (user.isAdmin) {
    return next();                              // proceed to admin handler
  }
  return res.status(403).json({ error: "forbidden" });
}

What's the async bug? What's the user-visible impact? How do you fix it?

if (user) { return next(); }   // user is a Promise → ALWAYS truthy → everyone is "admin"

export async function requireAdmin(req, res, next) {
  const user = await getUser(req.session.userId);   // now a real User
  if (!user?.isAdmin) {
    return res.status(403).json({ error: "forbidden" });
  }
  return next();
}

Snippet 2 — The save that reports success¶

// JavaScript — a service method behind POST /profile
async function updateProfile(userId, patch) {
  const updated = { ...patch, updatedAt: Date.now() };

  db.users.update(userId, updated).catch(() => {});   // "be resilient"

  return { ok: true, profile: updated };
}

What's the async bug? What's the user-visible impact? How do you fix it?

async function updateProfile(userId, patch) {
  const updated = { ...patch, updatedAt: Date.now() };
  await db.users.update(userId, updated);   // throws on failure → 500, logged
  return { ok: true, profile: updated };
}

try {
  await db.users.update(userId, updated);
} catch (err) {
  logger.error({ err, userId }, "profile update failed");
  return { ok: false, error: "could not save" };   // honest response
}

Snippet 3 — The welcome email nobody sent¶

// TypeScript — signup flow
async function signup(input: SignupInput): Promise<{ id: string }> {
  const user = await db.users.create(input);

  sendWelcomeEmail(user.email);     // kick off the welcome email
  trackSignup(user.id);             // analytics

  return { id: user.id };
}

async function sendWelcomeEmail(to: string) {
  const template = await loadTemplate("welcome");   // can throw: file missing
  await mailer.send({ to, subject: "Welcome!", html: template(/* ... */) });
}

What's the async bug? What's the user-visible impact? How do you fix it?

const user = await db.users.create(input);
await sendWelcomeEmail(user.email);   // failure → signup fails loudly, can retry

const user = await db.users.create(input);
void sendWelcomeEmail(user.email).catch(err =>
  logger.error({ err, userId: user.id }, "welcome email failed"));
void trackSignup(user.id).catch(err =>
  logger.warn({ err }, "signup tracking failed"));
return { id: user.id };

Snippet 4 — The handler that crashes the server later¶

// JavaScript — Express handler; the server has run fine for months
app.post("/orders/:id/ship", async (req, res) => {
  const order = await db.orders.find(req.params.id);

  warehouse.dispatch(order);            // tell the warehouse to ship

  res.json({ status: "shipping" });     // respond to the client
});

// warehouse.dispatch is async and can reject if the warehouse API is down
async function dispatch(order) { /* await fetch(warehouseUrl, ...) */ }

What's the async bug? What's the user-visible impact? How do you fix it?

app.post("/orders/:id/ship", async (req, res, next) => {
  try {
    const order = await db.orders.find(req.params.id);
    await warehouse.dispatch(order);          // failure → caught → proper 502
    res.json({ status: "shipping" });
  } catch (err) {
    next(err);                                // error middleware, no process crash
  }
});

Snippet 5 — Loading the dashboard, all or nothing¶

// TypeScript — assembling a dashboard from independent widgets
async function loadDashboard(userId: string) {
  const [profile, billing, recommendations, activity] = await Promise.all([
    fetchProfile(userId),
    fetchBilling(userId),
    fetchRecommendations(userId),   // ML service, occasionally slow/down
    fetchActivity(userId),
  ]);

  return { profile, billing, recommendations, activity };
}

What's the async bug? What's the user-visible impact? How do you fix it?

async function loadDashboard(userId: string) {
  const [profile, billing, recommendations, activity] = await Promise.allSettled([
    fetchProfile(userId),
    fetchBilling(userId),
    fetchRecommendations(userId),
    fetchActivity(userId),
  ]);

  return {
    profile: unwrap(profile),                       // critical: rethrow if needed
    billing: unwrap(billing),
    recommendations: ok(recommendations) ?? null,   // optional: null on failure
    activity: ok(activity) ?? [],
  };
}

Snippet 6 — Deleting the files one by one¶

// JavaScript — cleaning up a user's uploaded files on account deletion
async function deleteUserFiles(fileIds) {
  fileIds.forEach(async (id) => {
    await storage.delete(id);          // S3 delete
  });

  console.log(`Deleted ${fileIds.length} files`);
  return { deleted: fileIds.length };
}

What's the async bug? What's the user-visible impact? How do you fix it?

// Parallel, fails loudly, actually waits:
async function deleteUserFiles(fileIds) {
  await Promise.all(fileIds.map((id) => storage.delete(id)));
  return { deleted: fileIds.length };
}

// If you need bounded concurrency, use p-limit / a semaphore; if you must
// tolerate partial failure, use allSettled and report which deletes failed.

Snippet 7 — The Python audit log that ran nowhere¶

# Python (asyncio) — FastAPI-style handler recording a sensitive action
import asyncio

async def write_audit(actor_id: str, action: str) -> None:
    await audit_db.insert(actor_id=actor_id, action=action)   # can raise

async def transfer_funds(actor_id: str, amount: int) -> dict:
    await ledger.move(actor_id, amount)

    write_audit(actor_id, f"transfer:{amount}")   # record who did it

    return {"status": "ok"}

What's the async bug? What's the user-visible impact? How do you fix it?

async def transfer_funds(actor_id: str, amount: int) -> dict:
    await ledger.move(actor_id, amount)
    await write_audit(actor_id, f"transfer:{amount}")   # actually runs, raises on failure
    return {"status": "ok"}

task = asyncio.create_task(write_audit(actor_id, f"transfer:{amount}"))
task.add_done_callback(lambda t: t.exception() and log.error("audit failed", exc_info=t.exception()))
_background.add(task); task.add_done_callback(_background.discard)   # keep a strong ref

Snippet 8 — The price check that trusts a Promise¶

// TypeScript — checkout server validating the price the client sent
async function getCurrentPrice(sku: string): Promise<number> {
  const p = await pricing.lookup(sku);
  return p.amountCents;
}

async function checkout(req: CheckoutRequest): Promise<CheckoutResult> {
  const expected = getCurrentPrice(req.sku);   // no await

  if (req.clientPriceCents === expected) {      // client-supplied price vs "server" price
    return charge(req);
  }
  throw new PriceMismatchError();
}

What's the async bug? What's the user-visible impact? How do you fix it?

async function checkout(req: CheckoutRequest): Promise<CheckoutResult> {
  const expected = await getCurrentPrice(req.sku);   // real number
  if (req.clientPriceCents !== expected) {
    throw new PriceMismatchError();
  }
  return charge(req);
}

Snippet 9 — The retry that swallowed its own failure¶

// JavaScript — a retry helper used to harden flaky downstream calls
async function withRetry(fn, attempts = 3) {
  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (err) {
      // transient — try again
    }
  }
}

// usage:
const result = await withRetry(() => paymentApi.charge(order));
processPayment(result);

What's the async bug? What's the user-visible impact? How do you fix it?

async function withRetry(fn, attempts = 3) {
  let lastErr;
  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (err) {
      lastErr = err;
      logger.warn({ err, attempt: i + 1 }, "retrying");
      await delay(backoff(i));        // and back off between attempts
    }
  }
  throw lastErr;                      // exhausted retries → propagate the real cause
}

Snippet 10 — The cache warmer that looks reckless¶

// TypeScript — on startup, kick off a background cache warm-up.
// A reviewer flagged this as a "floating promise". Are they right?
function startServer() {
  app.listen(3000);

  // Fire-and-forget: warm the cache in the background; do NOT block startup.
  void warmCache().catch((err) => {
    logger.error({ err }, "cache warm-up failed; serving cold");
    metrics.increment("cache.warmup.failed");
  });
}

async function warmCache(): Promise<void> {
  const hot = await db.topProducts(100);
  for (const p of hot) cache.set(p.id, p);   // idempotent: re-runs harmlessly
}

What's the async bug? What's the user-visible impact? How do you fix it?

Snippet 11 — The Python gather that lost a writer¶

# Python (asyncio) — fan out writes to three regional replicas
import asyncio

async def replicate(record: dict) -> None:
    await asyncio.gather(
        write_region("us-east", record),
        write_region("eu-west", record),
        write_region("ap-south", record),
    )
    metrics.incr("replicated")

async def write_region(region: str, record: dict) -> None:
    await regional_db[region].put(record)   # can raise on a regional outage

What's the async bug? What's the user-visible impact? How do you fix it?

async def replicate(record: dict) -> None:
    results = await asyncio.gather(
        write_region("us-east", record),
        write_region("eu-west", record),
        write_region("ap-south", record),
        return_exceptions=True,
    )
    failures = [r for r in results if isinstance(r, Exception)]
    for err in failures:
        log.error("replica write failed", exc_info=err)
    metrics.incr("replicated", len(results) - len(failures))
    if len(failures) == len(results):
        raise ReplicationError("all replicas failed")   # your own quorum policy

Snippet 12 — The total that was never summed¶

// TypeScript — computing an order total from line items
async function lineItemTotal(item: LineItem): Promise<number> {
  const price = await pricing.lookup(item.sku);
  return price.amountCents * item.qty;
}

async function orderTotal(items: LineItem[]): Promise<number> {
  let total = 0;
  items.forEach(async (item) => {
    total += await lineItemTotal(item);
  });
  return total;                       // <-- returned here
}

What's the async bug? What's the user-visible impact? How do you fix it?

async function orderTotal(items: LineItem[]): Promise<number> {
  const amounts = await Promise.all(items.map(lineItemTotal));   // map keeps the promises
  return amounts.reduce((sum, n) => sum + n, 0);
}

let total = 0;
for (const item of items) total += await lineItemTotal(item);   // each await actually waits
return total;

Snippet 13 — The two-step checkout¶

// JavaScript — reserve inventory, then charge. Both are async.
async function placeOrder(order) {
  const reservation = reserveInventory(order);   // (1)
  const charge = await chargeCard(order);         // (2)

  if (charge.ok) {
    await confirmReservation(reservation);        // (3) pass the reservation along
    return { status: "confirmed" };
  }
  return { status: "declined" };
}

What's the async bug? What's the user-visible impact? How do you fix it?

async function placeOrder(order) {
  const reservation = await reserveInventory(order);   // hold stock first; throws if unavailable
  try {
    const charge = await chargeCard(order);
    if (!charge.ok) {
      await releaseReservation(reservation);           // give the stock back
      return { status: "declined" };
    }
    await confirmReservation(reservation);             // real reservation object
    return { status: "confirmed" };
  } catch (err) {
    await releaseReservation(reservation);             // compensate on any failure
    throw err;
  }
}

Snippet 14 — The metrics flush on shutdown¶

// TypeScript — graceful shutdown hook
process.on("SIGTERM", () => {
  server.close();

  metrics.flush();         // push buffered metrics to the collector (async)
  logger.flush();          // flush buffered logs (async)

  process.exit(0);         // exit
});

What's the async bug? What's the user-visible impact? How do you fix it?

process.on("SIGTERM", async () => {
  await new Promise<void>((resolve) => server.close(() => resolve()));   // drain connections
  await Promise.allSettled([
    withTimeout(metrics.flush(), 5_000),
    withTimeout(logger.flush(), 5_000),
  ]);
  process.exit(0);                                                       // only now
});

Summary — patterns of spotting¶

You don't catch async error-handling bugs by spotting a bad line — you catch them by asking, at every async call site: did the work actually finish, and would I hear about it if it failed? The repeatable moves from these fourteen snippets:

• Treat every async result as suspect until it's awaited or explicitly handled. A Promise is a promise, not a value: it's truthy in an if, never === a number, has none of the resolved object's fields. The auth bug (Snippet 1), the price bypass (Snippet 8), the $0 total (Snippet 12), and the orphaned charge (Snippet 13) are all the same root cause — a Promise dereferenced as if it were T. This is the Forgotten await.
• An empty catch is a data-loss generator. .catch(() => {}) and a catch {} that neither logs nor rethrows convert a known failure into a silent, mislabeled "success" (Snippets 2, 9). If you catch, you must do something: rethrow, log, retry, or compensate. Swallowed Rejection thrives wherever a catch block is empty or a retry loop falls through.
• A bare async call in a request handler or shutdown hook is a time bomb. It works until the dependency has a bad day, then the unhandled rejection crashes the process after the response was sent (Snippets 4, 13) — or the process exits before the flush runs (Snippet 14). The blast radius is wildly larger than the cause. This is the Floating Promise.
• Fire-and-forget is only acceptable with logging and idempotency. Background work whose failure isn't logged + measured is invisible until users complain (Snippets 3, 7). Python is sharper: a forgotten await means the coroutine never runs at all. Contrast with the correct version (Snippet 10): void + .catch(log+metric) + idempotent + non-critical = fine. This is Fire-and-Forget Without Logging.
• forEach(async …) does not wait — ever. forEach discards the promises its callback returns, so the loop "finishes" before any await resolves (Snippets 6, 12). Use map + Promise.all to parallelize, or for...of to serialize. Both keep the promises; forEach throws them away.
• Promise.all / asyncio.gather are fail-fast and lose the siblings. The first rejection discards every other result — including other failures, which then become silent unhandled rejections (Snippets 5, 11). Use allSettled / gather(return_exceptions=True) / TaskGroup and apply an explicit policy when partial success is acceptable.

The meta-lesson: async errors don't fall on the floor loudly — they fall silently, after the response was already sent. The function returned { ok: true }; the write failed. The endpoint said "shipping"; the dispatch crashed the server a tick later. The audit "ran"; the coroutine was never scheduled. When you read async code, don't ask "does this look right?" — ask "if this Promise rejects at 3 a.m., who finds out, and when?"

Related Topics¶

• tasks.md — broken async programs to fix from the writing side (same four anti-patterns).
• optimize.md — implementations to make correct and properly parallel.
• Execution-Shape find-bug — await-in-loop, Promise-chain hell, mixing callbacks and promises.
• Misuse find-bug — Promise-constructor anti-pattern and async without await.
• Concurrency Anti-Patterns — the multi-thread sibling: locks, races, deadlocks.
• Error Handling (Clean Code) — the positive patterns for propagating failures.
• Backend / Distributed Systems — fan-out, retry, timeout, and saga compensation at the network layer.