DEV Community: Zain Alsaadi

One Request, Many Callers: Coalescing Duplicate fetch() Calls in JavaScript

Zain Alsaadi — Sun, 18 Oct 2026 20:45:47 +0000

Open the network tab of almost any single-page app and you'll find it: the same /api/me request fired three, five, sometimes ten times within a few milliseconds. The header wants the current user, so does the sidebar, the avatar, and the settings link. Every component calls fetch() independently, and none of them knows the others asked.

On the server, the same thing happens when a cache entry expires and a hundred concurrent requests all miss it at once and hit the database together. That's the "thundering herd" (or "cache stampede") problem.

The fix for both is request coalescing: while a request for a given key is in flight, every other caller gets the same promise instead of starting a new request. Data libraries like TanStack Query and SWR do this internally, but the core idea fits in about 40 lines, and understanding it helps you spot the edge cases those libraries handle for you.

All code here runs unmodified on Node.js 20+ (which ships fetch globally) and in modern browsers.

The naive version and its bugs

The obvious implementation is a Map from URL to promise:

const inFlight = new Map();
function naiveFetch(url) {
  if (!inFlight.has(url)) inFlight.set(url, fetch(url));
  return inFlight.get(url);
}

This has three problems:

It never forgets. Entries stay in the map forever, so this is a memory leak that also serves stale data.
A Response body can only be read once. If two callers both call res.json() on the same Response, the second one throws TypeError: Body is unusable: Body has already been read.
Failures are cached. One network blip and that URL is broken until the page reloads.

A correct version

// coalesce.mjs
export function createCoalescingFetch({ ttlMs = 0 } = {}) {
  const inFlight = new Map(); // url -> Promise<{status, headers, body}>

  return async function coalescedFetch(url, { signal } = {}) {
    let shared = inFlight.get(url);

    if (!shared) {
      shared = (async () => {
        const res = await fetch(url);
        const body = await res.text(); // read once, share the text
        if (!res.ok) throw new Error(`HTTP ${res.status} for ${url}`);
        return { status: res.status, headers: Object.fromEntries(res.headers), body };
      })();

      inFlight.set(url, shared);

      shared.then(
        () => {
          if (ttlMs > 0) setTimeout(() => inFlight.delete(url), ttlMs).unref?.();
          else inFlight.delete(url);
        },
        () => inFlight.delete(url) // never cache failures
      );
    }

    if (!signal) return shared;

    // Let one caller give up without cancelling the request for everyone.
    signal.throwIfAborted();
    return new Promise((resolve, reject) => {
      const onAbort = () => reject(signal.reason);
      signal.addEventListener("abort", onAbort, { once: true });
      shared.then(resolve, reject).finally(() =>
        signal.removeEventListener("abort", onAbort)
      );
    });
  };
}

Let's walk through the decisions.

Read the body once, share the result. The shared promise resolves to a plain object containing the body text, not the Response. Every caller can read it as many times as they like. (Callers share the same object, so treat it as read-only, or Object.freeze it if you want that enforced.)

Evict on settle. As soon as the request finishes, the entry is removed, so the next call goes to the network again. Coalescing is about de-duplicating concurrent work, not caching. If you do want a short cache, ttlMs keeps the settled promise around a little longer. The .unref?.() call stops that timer from keeping a Node.js process alive. In browsers, setTimeout returns a number, so the optional call simply does nothing.

Never cache failures. The rejection handler deletes the entry immediately. Everyone who was already waiting gets the same error (which is correct, since they asked at the same moment), but the next caller retries.

Isolate cancellation. This is the subtle one. If you passed a caller's AbortSignal into the shared fetch(), then the first component to unmount would cancel the request for every component. Instead, the shared request runs without a signal, and each caller races the shared promise against its own signal. A caller that aborts gets rejected right away, and everyone else is unaffected.

Proving it works

Claims about concurrency are cheap, so let's test them against a real HTTP server that counts how many requests it receives. The server waits 100 ms before responding, to give the callers time to overlap:

// demo.mjs
import http from "node:http";
import assert from "node:assert/strict";
import { createCoalescingFetch } from "./coalesce.mjs";

let hits = 0;
let failNext = false;
const server = http.createServer((req, res) => {
  hits++;
  setTimeout(() => {
    if (failNext) {
      failNext = false;
      res.writeHead(503).end("busy");
      return;
    }
    res.writeHead(200, { "content-type": "application/json" });
    res.end(JSON.stringify({ path: req.url, hit: hits }));
  }, 100);
});
await new Promise((r) => server.listen(0, r));
const base = `http://127.0.0.1:${server.address().port}`;

Ten concurrent callers, one request:

const get = createCoalescingFetch();
const results = await Promise.all(
  Array.from({ length: 10 }, () => get(`${base}/user/1`))
);
assert.equal(hits, 1);
assert.ok(results.every((r) => r === results[0]));
console.log("10 callers ->", hits, "request");

Once settled, the next call is fresh, and different URLs are never merged:

await get(`${base}/user/1`);
assert.equal(hits, 2);
console.log("after settle ->", hits, "requests");

await Promise.all([get(`${base}/a`), get(`${base}/b`)]);
assert.equal(hits, 4);
console.log("two urls ->", hits, "requests");

Failures are shared, then evicted:

failNext = true;
const outcomes = await Promise.allSettled([get(`${base}/x`), get(`${base}/x`)]);
assert.equal(hits, 5);
assert.ok(outcomes.every((o) => o.status === "rejected"));
const retry = await get(`${base}/x`);
assert.equal(hits, 6);
assert.equal(retry.status, 200);
console.log("failure shared then evicted ->", hits, "requests");

One caller aborting doesn't cancel the other:

const ac = new AbortController();
const p1 = get(`${base}/slow`, { signal: ac.signal });
const p2 = get(`${base}/slow`);
setTimeout(() => ac.abort(new Error("user navigated away")), 20);
const [r1, r2] = await Promise.allSettled([p1, p2]);
assert.equal(r1.status, "rejected");
assert.equal(r1.reason.message, "user navigated away");
assert.equal(r2.status, "fulfilled");
assert.equal(hits, 7);
console.log("abort isolated ->", hits, "requests");

A short TTL turns it into a micro-cache:

const cached = createCoalescingFetch({ ttlMs: 500 });
await cached(`${base}/cfg`);
await cached(`${base}/cfg`);
assert.equal(hits, 8);
await new Promise((r) => setTimeout(r, 600));
await cached(`${base}/cfg`);
assert.equal(hits, 9);
console.log("ttl micro-cache ->", hits, "requests");

server.close();
console.log("all checks passed");

Running it:

$ node demo.mjs
10 callers -> 1 request
after settle -> 2 requests
two urls -> 4 requests
failure shared then evicted -> 6 requests
abort isolated -> 7 requests
ttl micro-cache -> 9 requests
all checks passed

When to use it, and when not to

Good fits:

GET requests for data that many parts of the UI need at once (current user, feature flags, config)
Server-side calls to upstream APIs or slow queries, where a cache miss under load would otherwise hit the backend once per concurrent request
Expensive non-HTTP async work, too. Swap fetch(url) for any async function and the URL for any string key.

Don't use it for:

Non-idempotent requests. Two POST /orders calls are two orders. Never merge them.
Requests that differ by more than the URL. If headers like Authorization or Accept-Language change the response, include them in the key. Otherwise user A can receive user B's data, which on a server is a security bug, not a performance bug.
Streaming or huge responses. This version buffers the whole body into memory to share it.

Takeaways

Share the promise, not the Response, because a body can only be read once.
Delete the entry when the request settles, and always on failure.
Never let one caller's AbortSignal cancel shared work. Race it per caller instead.
Build the cache key from everything that changes the response.

Forty lines, no dependencies, and your network tab gets a lot quieter.

Note: An AI assistant helped draft this post; all code was run and tested (Node.js 20.19).

Your Logs Are an API: Testing Python Logging with pytest's caplog

Zain Alsaadi — Sun, 18 Oct 2026 20:45:17 +0000

At 3 a.m., during an incident, your logs are the only interface you have to production. Dashboards, alerts, and log queries all depend on them: an alert fires on level=ERROR, a saved search filters on order_id, a compliance check makes sure no password ever reaches the log pipeline.

That makes your log output an API. Other systems depend on its shape, yet most codebases never test it. Someone downgrades an error to a warning, renames order_id to orderId, or adds a debug line that dumps a whole request body, and no test fails.

pytest has a built-in fixture for this, caplog. In this post we'll use it to test four things:

The right level is used for the right situation
Structured fields passed through extra= are present
Unexpected errors carry a traceback
A JSON formatter and a redaction filter behave correctly, together

All code runs on Python 3.13 with pytest 9 and needs nothing beyond the standard library and pytest.

The code under test

Here is a small checkout function. It tells three different stories: a captured payment (INFO), a declined card (WARNING, because it's a normal business outcome and shouldn't page anyone), and a gateway failure (ERROR with a traceback, because it should).

# checkout.py
import logging

logger = logging.getLogger("shop.checkout")


class PaymentDeclined(Exception):
    pass


def charge(order_id, amount_cents, gateway):
    logger.debug("charging order", extra={"order_id": order_id})
    try:
        gateway(amount_cents)
    except PaymentDeclined:
        logger.warning(
            "payment declined",
            extra={"order_id": order_id, "amount_cents": amount_cents},
        )
        return False
    except Exception:
        logger.exception("gateway error", extra={"order_id": order_id})
        raise
    logger.info("payment captured", extra={"order_id": order_id,
                                            "amount_cents": amount_cents})
    return True

The extra= dictionary is the standard library's way of attaching structured fields. Each key becomes an attribute on the LogRecord, which is exactly what we'll assert on.

Test 1: levels and fields

caplog.records is a list of the actual LogRecord objects that were emitted. Asserting on records instead of formatted strings makes the tests resilient to formatting changes:

import logging

from checkout import PaymentDeclined, charge


def ok_gateway(amount):
    return None


def declining_gateway(amount):
    raise PaymentDeclined()


def test_success_logs_info_with_order_id(caplog):
    caplog.set_level(logging.INFO, logger="shop.checkout")

    assert charge("ord-42", 1999, ok_gateway) is True

    [record] = caplog.records
    assert record.levelname == "INFO"
    assert record.getMessage() == "payment captured"
    assert record.order_id == "ord-42"
    assert record.amount_cents == 1999


def test_decline_is_a_warning_not_an_error(caplog):
    caplog.set_level(logging.INFO, logger="shop.checkout")

    assert charge("ord-7", 500, declining_gateway) is False

    assert [r.levelname for r in caplog.records] == ["WARNING"]
    assert caplog.records[0].order_id == "ord-7"

Two details matter here:

caplog.set_level(..., logger=...) scopes the level change to one logger and restores it after the test, so tests don't leak configuration into each other.
[record] = caplog.records is a small trick: the unpacking fails if there isn't exactly one record. That catches accidental duplicate logging, which is a common bug when a handler gets attached twice.

The second test protects a decision that is easy to undo by accident. If someone "fixes" the decline path to use logger.error, your on-call rotation starts getting paged for expired credit cards. Now a test fails first.

Test 2: debug output stays at debug

Use the caplog.at_level context manager when a test needs different levels in different phases. caplog.messages gives you just the formatted message strings:

def test_debug_line_only_appears_at_debug(caplog):
    with caplog.at_level(logging.INFO, logger="shop.checkout"):
        charge("ord-1", 100, ok_gateway)
    assert "charging order" not in caplog.messages

    caplog.clear()
    with caplog.at_level(logging.DEBUG, logger="shop.checkout"):
        charge("ord-1", 100, ok_gateway)
    assert caplog.messages[0] == "charging order"

caplog.clear() resets the captured records between phases.

Test 3: errors carry a traceback

A log line that says gateway error without a stack trace is almost useless. logger.exception() attaches exc_info to the record, so assert that it's there and has the right type:

import pytest


def broken_gateway(amount):
    raise TimeoutError("gateway timed out")


def test_unexpected_error_logs_traceback(caplog):
    caplog.set_level(logging.ERROR, logger="shop.checkout")

    with pytest.raises(TimeoutError):
        charge("ord-9", 100, broken_gateway)

    [record] = caplog.records
    assert record.exc_info is not None
    assert record.exc_info[0] is TimeoutError

This test fails if someone replaces logger.exception(...) with logger.error(...), which silently drops the traceback.

Test 4: the formatter and the redaction filter

Most production setups ship JSON logs. Here is a minimal formatter that copies every extra= field into the JSON, plus a filter that masks sensitive keys before anything is written:

# app_logging.py
import json
import logging

_RESERVED = set(vars(logging.makeLogRecord({}))) | {"message", "asctime"}
SENSITIVE_KEYS = {"password", "token", "card_number"}


class JsonFormatter(logging.Formatter):
    def format(self, record):
        payload = {
            "level": record.levelname,
            "logger": record.name,
            "message": record.getMessage(),
        }
        # Anything passed via extra=... becomes an attribute on the record.
        for key, value in vars(record).items():
            if key not in _RESERVED:
                payload[key] = value
        if record.exc_info:
            payload["exception"] = self.formatException(record.exc_info)
        return json.dumps(payload, default=str)


class RedactFilter(logging.Filter):
    def filter(self, record):
        for key in SENSITIVE_KEYS:
            if hasattr(record, key):
                setattr(record, key, "[REDACTED]")
        return True

The _RESERVED trick builds the set of attribute names every LogRecord has by default, so anything else on the record must have come from extra=.

You can unit-test both classes without any logger at all, because logging.makeLogRecord() builds a record from a dict:

import json

from app_logging import JsonFormatter, RedactFilter


def make_record(**extra):
    return logging.makeLogRecord(
        {"name": "shop.checkout", "levelname": "INFO", "levelno": 20,
         "msg": "user %s logged in", "args": ("alice",), **extra}
    )


def test_formatter_emits_valid_json_with_extras():
    line = JsonFormatter().format(make_record(order_id="ord-42"))
    data = json.loads(line)
    assert data == {
        "level": "INFO",
        "logger": "shop.checkout",
        "message": "user alice logged in",
        "order_id": "ord-42",
    }


@pytest.mark.parametrize("field", ["password", "token", "card_number"])
def test_redact_filter_masks_sensitive_fields(field):
    record = make_record(**{field: "s3cret"})
    assert RedactFilter().filter(record) is True
    data = json.loads(JsonFormatter().format(record))
    assert data[field] == "[REDACTED]"
    assert "s3cret" not in json.dumps(data)

Comparing the whole dict with == is deliberate. It catches extra fields leaking into the output, not just missing ones.

Test 5: the whole pipeline

Unit tests on the formatter are good, but the real bug is often in the wiring. caplog.handler is a real logging.Handler, so you can give it your production formatter and filter and assert on the final text with caplog.text:

def test_full_pipeline_through_a_real_handler(caplog):
    logger = logging.getLogger("shop.checkout")
    caplog.handler.setFormatter(JsonFormatter())
    caplog.handler.addFilter(RedactFilter())
    caplog.set_level(logging.INFO, logger="shop.checkout")

    logger.info("login", extra={"user": "alice", "password": "hunter2"})

    data = json.loads(caplog.text.strip())
    assert data["user"] == "alice"
    assert data["password"] == "[REDACTED]"

A fresh handler is created for every test, so this configuration doesn't leak into other tests.

Running it

$ python -m pytest -q
.........                                                                [100%]
9 passed in 0.01s

Takeaways

Assert on caplog.records, not strings. Records give you the level, the logger name, exc_info, and every extra= field as attributes.
Use the [record] = caplog.records unpacking to catch duplicate log lines for free.
Scope levels with set_level(..., logger=...) or at_level. Both restore the previous state automatically.
Test redaction explicitly. A parametrized test over your sensitive keys is cheap insurance against a compliance incident.
Test the wiring once by attaching your real formatter and filters to caplog.handler.

If a dashboard, alert, or audit depends on a log line, that log line deserves a test.

Note: An AI assistant helped draft this post; all code was run and tested (Python 3.13, pytest 9.1).