Async Misuse Anti-Patterns — Find the Bug¶

Category: Async Anti-Patterns → Misuse — async machinery applied where it doesn't help, or applied wrong. Covers (collectively): Promise Constructor Anti-Pattern · async Without await

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

What's the misuse? What's the concrete bug — lost error, hang, double-resolve, or just a pointless hop? How would you fix it?

These two anti-patterns share a deceptive quality: the code usually runs and often passes the happy-path test. The damage shows up only when something rejects, throws, or fires twice — i.e. exactly when you most need the error to surface. A wrapped Promise that drops its rejection looks identical to a correct one until the inner call fails. An async Promise executor looks like defensive code until a throw turns into a hang that no try/catch can catch. A pointless async is harmless until a caller trusts the await to mean "the work finished."

How to use this file: read each snippet, decide lost error / hang / double-resolve / no-op, and write your fix before expanding the answer. The skill is noticing the misuse, not recalling the name. Not every snippet is guilty — one is the correct, idiomatic way to bridge a callback API and only looks like the anti-pattern.

Table of Contents¶

1. The wrapper that forwards the value
2. Defensive async around an await
3. Promisifying readFile by hand
4. The validator that returns a Promise
5. A delay helper
6. Fetch with a timeout
7. Waiting for an image to load
8. The cache that wraps a lookup
9. An asyncio coroutine that wraps a future
10. The retry helper
11. Config loader, now async
12. Draining a stream into a string
13. The map that became async
14. Bridging an EventEmitter once
15. The Python sleep wrapper

Snippet 1 — The wrapper that forwards the value¶

// JS — a thin wrapper added "to normalize the return shape"
function fetchUser(id) {
  return new Promise((resolve) => {
    api.get(`/users/${id}`).then((res) => {
      resolve(res.data);
    });
  });
}

// caller
try {
  const user = await fetchUser(42);
  render(user);
} catch (err) {
  showError(err);   // why does this never fire when the API 500s?
}

What's the misuse? What's the concrete bug? How would you fix it?

function fetchUser(id) {
  return api.get(`/users/${id}`).then((res) => res.data);
}
// or, clearer:
async function fetchUser(id) {
  const res = await api.get(`/users/${id}`);
  return res.data;
}

Snippet 2 — Defensive async around an await¶

// JS — "make sure we always settle, even on error" wrapper around a flaky DB call
function loadProfile(id) {
  return new Promise(async (resolve, reject) => {
    const conn = await pool.acquire();
    const row = await conn.query("SELECT * FROM profiles WHERE id = $1", [id]);
    if (!row) {
      throw new Error("profile not found");   // we expect this to reject the promise
    }
    resolve(row);
    pool.release(conn);
  });
}

What's the misuse? What's the concrete bug? How would you fix it?

async function loadProfile(id) {
  const conn = await pool.acquire();
  try {
    const row = await conn.query("SELECT * FROM profiles WHERE id = $1", [id]);
    if (!row) throw new Error("profile not found");   // now correctly rejects
    return row;
  } finally {
    pool.release(conn);                                // always runs
  }
}

Snippet 3 — Promisifying readFile by hand¶

// JS — wrapping a Node callback API, no util.promisify available here
function readConfig(path) {
  return new Promise((resolve, reject) => {
    fs.readFile(path, "utf8", (err, data) => {
      if (err) reject(err);
      resolve(JSON.parse(data));
    });
  });
}

What's the misuse? What's the concrete bug? How would you fix it?

function readConfig(path) {
  return new Promise((resolve, reject) => {
    fs.readFile(path, "utf8", (err, data) => {
      if (err) return reject(err);          // return: don't fall through
      try {
        resolve(JSON.parse(data));          // parse errors reject, not crash
      } catch (e) {
        reject(e);
      }
    });
  });
}

Snippet 4 — The validator that returns a Promise¶

// TS — input validation in a request pipeline
async function validateOrder(order: Order): Promise<void> {
  if (!order.items.length) throw new ValidationError("empty order");
  if (order.total <= 0) throw new ValidationError("non-positive total");
  if (order.items.some((i) => i.qty < 1)) throw new ValidationError("bad qty");
}

// caller
async function handle(req: Request) {
  validateOrder(req.order);          // throws if invalid... right?
  return submit(req.order);
}

What's the misuse? What's the concrete bug? How would you fix it?

function validateOrder(order: Order): void {       // sync; throws synchronously
  if (!order.items.length) throw new ValidationError("empty order");
  if (order.total <= 0) throw new ValidationError("non-positive total");
  if (order.items.some((i) => i.qty < 1)) throw new ValidationError("bad qty");
}

Snippet 5 — A delay helper¶

// JS — a sleep utility used across the codebase
function delay(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

await delay(200);

What's the misuse? What's the concrete bug? How would you fix it?

Snippet 6 — Fetch with a timeout¶

// JS — add a timeout to a fetch by racing two promises
function fetchWithTimeout(url, ms) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => reject(new Error("timeout")), ms);
    fetch(url).then((res) => {
      resolve(res);
    });
  });
}

What's the misuse? What's the concrete bug? How would you fix it?

function fetchWithTimeout(url, ms) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), ms);
  return fetch(url, { signal: controller.signal })
    .finally(() => clearTimeout(timer));   // cleanup on success AND failure
}

Snippet 7 — Waiting for an image to load¶

// JS — preload an image before rendering a canvas
function loadImage(src) {
  return new Promise((resolve, reject) => {
    const img = new Image();
    img.onload = () => resolve(img);
    img.onerror = (e) => reject(e);
    img.src = src;
  });
}

What's the misuse? What's the concrete bug? How would you fix it?

Snippet 8 — The cache that wraps a lookup¶

// TS — memoizing an async lookup behind a Promise wrapper
const cache = new Map<string, Promise<User>>();

function getUser(id: string): Promise<User> {
  if (cache.has(id)) return cache.get(id)!;
  const p = new Promise<User>((resolve) => {
    db.findUser(id).then((u) => resolve(u));
  });
  cache.set(id, p);
  return p;
}

What's the misuse? What's the concrete bug? How would you fix it?

function getUser(id: string): Promise<User> {
  const cached = cache.get(id);
  if (cached) return cached;
  const p = db.findUser(id).catch((err) => {
    cache.delete(id);     // don't cache the failure; allow a retry
    throw err;            // still reject this caller
  });
  cache.set(id, p);
  return p;
}

Snippet 9 — An asyncio coroutine that wraps a future¶

# Python asyncio — "adapt" a low-level future-returning API into a coroutine
async def fetch_row(pool, query):
    fut = pool.execute(query)       # returns an awaitable Future
    result = None

    def on_done(f):
        nonlocal result
        result = f.result()         # may raise if the query failed

    fut.add_done_callback(on_done)
    return result

What's the misuse? What's the concrete bug? How would you fix it?

async def fetch_row(pool, query):
    return await pool.execute(query)   # waits; raises on failure

Snippet 10 — The retry helper¶

// TS — retry an async operation a few times
function withRetry<T>(op: () => Promise<T>, attempts: number): Promise<T> {
  return new Promise(async (resolve, reject) => {
    for (let i = 0; i < attempts; i++) {
      try {
        const result = await op();
        resolve(result);
        return;
      } catch (err) {
        if (i === attempts - 1) reject(err);
        await delay(2 ** i * 100);
      }
    }
  });
}

What's the misuse? What's the concrete bug? How would you fix it?

async function withRetry<T>(op: () => Promise<T>, attempts: number): Promise<T> {
  let lastErr: unknown;
  for (let i = 0; i < attempts; i++) {
    try {
      return await op();                 // returning resolves the promise
    } catch (err) {
      lastErr = err;
      if (i < attempts - 1) await delay(2 ** i * 100);   // no sleep after the last try
    }
  }
  throw lastErr;                         // throwing rejects the promise
}

Snippet 11 — Config loader, now async¶

// TS — config was synchronous; a teammate "made it async to be future-proof"
async function getConfig(): Promise<Config> {
  return {
    region: process.env.REGION ?? "us-east-1",
    retries: Number(process.env.RETRIES ?? 3),
    debug: process.env.DEBUG === "1",
  };
}

// hot path, called on every request
async function buildClient() {
  const cfg = await getConfig();
  return new ApiClient(cfg);
}

What's the misuse? What's the concrete bug? How would you fix it?

function getConfig(): Config {
  return {
    region: process.env.REGION ?? "us-east-1",
    retries: Number(process.env.RETRIES ?? 3),
    debug: process.env.DEBUG === "1",
  };
}

function buildClient() {
  return new ApiClient(getConfig());   // no await, no microtask hop, no contagion
}

Snippet 12 — Draining a stream into a string¶

// JS — collect a Node readable stream into a single string
function readStream(stream) {
  return new Promise((resolve, reject) => {
    let data = "";
    stream.on("data", (chunk) => {
      data += chunk;
    });
    stream.on("end", () => resolve(data));
  });
}

What's the misuse? What's the concrete bug? How would you fix it?

function readStream(stream) {
  return new Promise((resolve, reject) => {
    let data = "";
    stream.on("data", (chunk) => { data += chunk; });
    stream.on("end", () => resolve(data));
    stream.on("error", reject);          // the missing failure arm
  });
}

import { text } from "node:stream/consumers";
const data = await text(stream);          // handles end AND error for you

Snippet 13 — The map that became async¶

// TS — transform a list of ids into display labels
async function toLabel(id: number): Promise<string> {
  const prefix = id < 1000 ? "SM" : "LG";    // pure, synchronous
  return `${prefix}-${id.toString().padStart(5, "0")}`;
}

function labelsFor(ids: number[]): Promise<string>[] {
  return ids.map(toLabel);
}

// caller
const labels = labelsFor([1, 2, 3]);
console.log(labels.join(", "));   // expected "SM-00001, ..." — prints something odd

What's the misuse? What's the concrete bug? How would you fix it?

function toLabel(id: number): string {                 // sync, returns a string
  const prefix = id < 1000 ? "SM" : "LG";
  return `${prefix}-${id.toString().padStart(5, "0")}`;
}

function labelsFor(ids: number[]): string[] {
  return ids.map(toLabel);                             // string[], as expected
}

const labels = labelsFor([1, 2, 3]);
console.log(labels.join(", "));                        // "SM-00001, SM-00002, SM-00003"

Snippet 14 — Bridging an EventEmitter once¶

// JS — resolve when a worker emits its first "ready" event, reject on "error"
function waitForReady(worker) {
  return new Promise((resolve, reject) => {
    worker.once("ready", resolve);
    worker.once("error", reject);
  });
}

What's the misuse? What's the concrete bug? How would you fix it?

function waitForReady(worker) {
  return new Promise((resolve, reject) => {
    const onReady = (v) => { worker.off("error", onError); resolve(v); };
    const onError = (e) => { worker.off("ready", onReady); reject(e); };
    worker.once("ready", onReady);
    worker.once("error", onError);
  });
}
// Or simply: const { once } = require("node:events"); await once(worker, "ready");

Snippet 15 — The Python sleep wrapper¶

# Python asyncio — "rate-limit" helper that pauses, then runs the work
async def throttled(work):
    def _pause():
        time.sleep(0.5)        # wait half a second before doing the work
    _pause()
    return await work()

What's the misuse? What's the concrete bug? How would you fix it?

async def throttled(work):
    await asyncio.sleep(0.5)   # yields control; the loop keeps running
    return await work()

Summary — patterns of spotting¶

These two anti-patterns are quiet: the code usually runs and passes the happy-path test. You catch them by asking a small, repeatable set of questions.

• Is new Promise wrapping something that's already a Promise? If yes, it's the Promise Constructor anti-pattern — return the inner Promise (or await it) instead. The danger is almost always a dropped rejection: a wrapper with resolve but no reject/.catch leaves the outer Promise forever pending on failure (Snippets 1, 6, 8). Caching that pending Promise makes one transient error permanent (Snippet 8).
• Is the new Promise executor declared async? That is always wrong (no-async-promise-executor). The constructor discards the executor's return and its rejection, so a throw inside it becomes a hang the caller can never catch (Snippets 2, 10). Use a plain async function instead — it's a Promise factory where return resolves and throw rejects.
• Is the function async but contains no await? Then async is doing nothing useful and three things harmful: a wasted microtask hop (Snippet 11), type contagion that forces callers to await and can corrupt data (Promise<T> where T was expected — Snippet 13), and a misleading contract that turns synchronous throws into dropped rejections so callers forget to await (Snippet 4). Drop the keyword.
• When bridging a callback / event / timer API, did you wire every terminal arm? A hand-rolled bridge needs success and error: a missing reject/error-event arm hangs on failure (Snippet 12), and falling through after reject double-settles or crashes (Snippet 3). And clean up the losing listener to avoid leaks (Snippet 14).
• Resist false positives. new Promise around a timer (Snippet 5), an image's events (Snippet 7), or an EventEmitter (Snippet 14) is the correct, idiomatic use — there's no Promise being wrapped. The diagnostic is always: does this wrap an existing Promise (bad) or a non-Promise async source (fine)?
• An async function is only as concurrent as its most blocking line. A synchronous time.sleep/requests.get/CPU loop inside a coroutine stalls the whole event loop (Snippet 15) — the mirror image of pointless async.

The meta-lesson: async misuse rarely crashes on line one. It converts errors into silence (lost rejection), liveness into deadlock (the async-executor hang), and types into surprises (Promise<T> where you wanted T). When a Promise "never settles" or an error "never fires," look first at whether someone wrapped a Promise in a Promise, made an executor async, or decorated pure code with async.

Related Topics¶

• tasks.md — write-side exercises that build the same muscles: refactor the misuse out.
• optimize.md — flawed async implementations to make correct (and unwrap).
• junior.md — what each misuse looks like and why it's wrong, from scratch.
• middle.md — when these creep in and the small countermove that reverses them.
• senior.md — instrumenting unhandled rejections and hangs at scale.
• interview.md — Q&A across both anti-patterns.
• Error Handling Async Anti-Patterns — swallowed rejections and floating Promises, the sibling failure modes.
• Execution Shape Async Anti-Patterns — await in loops, Promise chains, callback/Promise mixing.
• Concurrency Anti-Patterns — the multi-thread sibling chapter.
• Clean Code → Error Handling — propagate, don't swallow.
• Clean Code → Concurrency — the positive patterns behind correct async.