DEV Community: Shubhra Pokhariya

Does Promise.all() Cancel Other Promises When One Rejects?

Shubhra Pokhariya — Tue, 10 Nov 2026 14:45:25 +0000

When Promise.all() rejects, the promise it returns settles with the first rejection reason, and that is all that changes. Nothing is cancelled. The other input promises keep going, the operations behind them keep running, and any side effect they perform still happens, after your code has already moved on to the error path.

The table comes from a three-operation reproduction on Node.js 22.23.4. Operation A fails early, B succeeds later, and C writes to a store later still. Timings are approximate. The order of events is the result.

What you might ask	What the run showed
Did the aggregate promise reject?	Yes, at about 50 ms, with the same error object A rejected with
Did B, an input promise, still settle?	Yes, it fulfilled at about 150 ms
Did C, the underlying operation, still run?	Yes, it wrote to the store at about 250 ms, after the aggregate had rejected
Can B's value be read through the aggregate?	No. It is only available from the promise `b` itself
Did anything cancel B or C?	No. `Promise.all()` has no concept of cancellation

That is where most explanations stop. The more useful question is what your code should do with work that is still running after a failure. The rest of this article covers how the promise combinators differ, what cooperative cancellation with AbortController can and cannot do, how to choose between the options, and why retrying the whole group after a partial failure can duplicate writes.

Why a rejected Promise.all() does not mean the work stopped

Picture a settings page with a Save all button. It sends three requests at once: profile, notification preferences and billing address.

await Promise.all([
  saveProfile(form.profile),
  saveNotifications(form.notifications),
  saveBillingAddress(form.billing),
]);

The billing request fails fast on validation. Promise.all() rejects, the catch block runs, and the page shows "Save failed, please try again." The user reads that as "nothing was saved." But the other two requests were already on the wire, and nothing told them to stop. Assume both complete a moment later. The user clicks Save again, and the same three requests go out a second time.

Nothing in that sequence is a bug in Promise.all(). It did what it is specified to do. The bug is the assumption that a rejected aggregate means the group of operations has stopped. The error described the aggregate promise, and the user took it to describe the work.

The same gap appears when you upload several files, call several endpoints inside an SDK method, or fan out data transforms. Whenever an operation has an effect outside the promise (a write, a message sent, a file created, a charge made), the distance between "the promise rejected" and "the work stopped" is where duplicate writes, stale screens and confusing logs come from. If the operations are pure reads whose results you discard, the same gap costs you some bandwidth and CPU and may not matter at all. The first job is to know which case you are in.

What Promise.all() actually does with its input promises

Three different things hide behind the word "promise" in this problem, and mixing them up causes most of the confusion.

Term	What it is	What controls it
Aggregate promise	The single promise `Promise.all()` returns	Settles once, on the first rejection or when every input has fulfilled
Input promises	The promises you pass in	Each settles on its own schedule, independent of the aggregate
Underlying operations	The real work: a request, a timer, a disk write, a computation	Whatever started it. A promise only reports on it

A promise is a report on an operation, not the operation. Its state tells you whether the report has come in. It does not tell you whether the work is running, finished or stopped.

The specification shows why Promise.all() cannot reach into the operations. For each element of the iterable, it converts the element to a promise and calls then on it with two functions. The fulfillment handler stores the value at that element's position and counts down the elements still pending. The rejection handler is the reject function of the aggregate promise itself. The algorithm is PerformPromiseAll in the ECMAScript specification. Four consequences follow.

The first rejection settles the aggregate. The first input to reject calls the aggregate's reject function. Any later call does nothing, because a promise settles only once.
Later successes are never delivered. The aggregate resolves only when a counter of pending inputs reaches zero, and the counter only goes down when an input fulfills. The input that rejected never counts down, so the counter never reaches zero. The values from the other inputs are collected into a list that nothing can read, and the aggregate's resolve function is never called.
Every input counts as handled. Attaching then handlers marks each input promise as handled. MDN states that rejections after the first are ignored and do not trigger unhandledrejection events.
Nothing in the algorithm touches the operations. The only thing Promise.all() does to an input is attach handlers, by calling then on the promise it gets from Promise.resolve(). It has no way to cancel, pause or inspect the work behind it.

One more detail that is easy to miss. In the common pattern Promise.all([a(), b(), c()]), JavaScript calls a, b and c before Promise.all() runs at all. If those functions start their work before they return a promise, which they usually do, that work is already underway when Promise.all() receives the promises. Promise.all() never calls your functions and does not start operations for you. It observes work that is already in motion. The one exception is a lazy thenable, an object whose then method only starts the work when it is called. Promise.all() passes each input through Promise.resolve(), and for a thenable that queues a job which calls its then. I checked this: the work begins a moment after Promise.all() has returned, instead of before. Promises returned by real APIs such as fetch do not behave that way.

MDN also notes that rejecting the aggregate does not unsubscribe the handlers attached to the inputs. Repeatedly passing the same long-lived pending promise to Promise.all() can accumulate handlers on it, even when another input rejects each time. A shared shutdown promise reused inside a loop is one way to run into that.

The smallest reproduction: what happens after Promise.all() rejects

Three timer-driven operations are enough to separate the aggregate, the inputs and the work. A rejects at about 50 ms. B fulfills at about 150 ms with a plain value. C writes to a store at about 250 ms, and the store stands in for anything outside the promise, such as a file, a row or a message. This is the core of 01-lifecycle.mjs, trimmed to the essentials.

import { createTimeline, sleep } from "./lib/timeline.mjs";

const { log } = createTimeline();
const store = []; // stands in for "something outside the promise"

function start(name, ms, behaviour) {
  log(`${name} started`);
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (behaviour === "reject") {
        reject(new Error(`${name} failed`));
      } else if (behaviour === "write") {
        store.push(name);
        log(`${name} side effect performed (store = [${store}])`);
        resolve(`${name} result`);
      } else {
        resolve(`${name} result`);
      }
    }, ms);
  });
}

const a = start("A", 50, "reject");
const b = start("B", 150, "value");
const c = start("C", 250, "write");

for (const [name, p] of [
  ["A", a],
  ["B", b],
  ["C", c],
]) {
  p.then(
    (v) => log(`${name} promise fulfilled with "${v}"`),
    (e) => log(`${name} promise rejected with "${e.message}"`),
  );
}

const aggregate = Promise.all([a, b, c]);
aggregate.then(
  () => log("AGGREGATE fulfilled"),
  (e) => log(`AGGREGATE rejected with "${e.message}"`),
);

The .then observers on a, b and c only record when each input settles. Promise.all() has already attached its own handlers to the same promises. This is the output from a real run on Node.js 22.23.4. The numbers change from run to run, and the order does not.

    0 ms  A started
    5 ms  B started
    5 ms  C started
   55 ms  A promise rejected with "A failed"
   55 ms  AGGREGATE rejected with "A failed"
  154 ms  B promise fulfilled with "B result"
  256 ms  C side effect performed (store = [C])
  256 ms  C promise fulfilled with "C result"

After 400 ms the script also checks the end state.

aggregate: rejected (A failed)
store: ["C"]
aggregate rejected with the very same error object as A: true
B value, read from the individual promise b: B result

What this shows. The aggregate settled about 200 ms before the last operation finished. B still fulfilled after the aggregate rejected, and C still performed its side effect after the aggregate rejected. The error the caller received is the object A rejected with, not a copy or a wrapper. B's value is still readable, but only from b, never from the aggregate.

What it does not show. These are simulated operations on timers. The run says nothing about how a particular HTTP client, database driver or file API behaves when its caller stops waiting. It also covers only operations that have no cancellation support. The cancellation case comes later.

What happens after the first rejection

A later success

Already covered by the timeline. The operation finishes, its side effect happens, and its promise fulfills. Its value is out of reach of the aggregate. If your cleanup code needs that value, for example the id of a resource that was just created, you have to keep a reference to the input promise yourself, or collect outcomes with Promise.allSettled() instead.

A later rejection, and whether it becomes an unhandled rejection in Node.js

It is easy to assume that once Promise.all() has rejected, the other failures have nobody listening and surface as unhandled rejections. The language-level answer is no, because Promise.all() attached a rejection handler to every input. The second script checks that on Node.js, where unhandled rejection reporting is a runtime feature and not part of the language. Three inputs reject at about 20, 60 and 90 ms, all passed to Promise.all().

Scenario 1: P1, P2, P3 reject at 20/60/90 ms; all passed to Promise.all
   22 ms  aggregate rejected with "P1"
unhandledRejection events in scenario 1: 0
Outcomes read from the individual promises afterwards:
  P1: rejected (P1)
  P2: rejected (P2)
  P3: rejected (P3)

Zero unhandledRejection events, even though two inputs rejected after the aggregate. The control case is a single rejecting promise that is not passed to anything.

Scenario 2 (control): one rejecting promise that is NOT passed to anything
  273 ms  process 'unhandledRejection' event for "LONE"
unhandledRejection events in scenario 2: 1

Node's process documentation says the unhandledRejection event fires when a promise is rejected and no handler is attached within one turn of the event loop. The command-line documentation says the default --unhandled-rejections mode is throw. With no unhandledRejection listener installed, the rejection is raised as an uncaught exception. The script checks that default in two child processes with no listener.

one rejection nobody handles -> exit code 1
Promise.all, a later input rejects -> exit code 0

The second child attaches a .catch() to the aggregate. That matters, because the aggregate is a promise too. If you call Promise.all() and never await it or attach a handler, the aggregate's own rejection is the unhandled one. Siblings are not.

So when an unhandled rejection does show up around a Promise.all() call, a likely cause is a promise that was never an input. That could be a timeout promise created on the side, a helper that returns a rejecting promise nobody awaited, or an aggregate nobody handled.

Multiple failures

The aggregate carries one rejection reason, the first one it observed. The other failures are not lost, since each input promise keeps its own state, and the script reads all three back with Promise.allSettled() after the fact. But that only works if you still hold the input promises. If the application needs every error, for logging, reporting or deciding what to clean up, collecting outcomes up front is simpler than reconstructing them later. Here are the same three failures, collected with Promise.allSettled().

Scenario 3: same shape of failures, collected with Promise.allSettled
  Q1: rejected (Q1)
  Q2: rejected (Q2)
  Q3: rejected (Q3)

Promise.all() vs Promise.allSettled() vs Promise.any() vs sequential await

The third script runs the same three operations under each strategy. A rejects at about 50 ms. B and C succeed at about 150 and 250 ms, and each writes to the store. For every strategy it records when the aggregate settled and which writes landed after that moment. Same Node.js 22.23.4 run.

Strategy	Settles at	Outcome	Writes before it settled	Writes after it settled
`Promise.all()`	about 50 ms	Rejects with A's error	none	B, C
`Promise.allSettled()`	about 250 ms	Fulfills with rejected, fulfilled, fulfilled	B, C	none
`Promise.any()`	about 150 ms	Fulfills with B's value	B	C
Sequential `await`	about 50 ms	Rejects with A's error	none	none, because B and C never started

None of the three combinators cancels anything. They differ in when they settle and in what they let you see.

Promise.all() settles as soon as any input rejects, or when all have fulfilled. It exposes the first failure and, on success, every value in input order. It is useful when you need one aggregate result that fulfills only if every input fulfills, and fail-fast rejection is appropriate. It does not give you rollback or atomicity. If the operations have side effects, you still need to decide what happens to the work that remains in progress.

Promise.allSettled() waits for every input to settle and never rejects because an input did. It fulfills with one object per input, in input order, each with a status of fulfilled or rejected and either a value or a reason. The price is time. It settled at about 250 ms in the run above, because it waited for the slowest operation even though A failed at 50 ms. Use it when every outcome matters, and not when you want to fail fast.

Promise.any() settles on the first fulfillment. It rejects only when every input rejects, with an AggregateError whose errors array lists the reasons in input order, not in the order they happened. The script confirms that with a slow first input and a fast second one.

Promise.any AggregateError.errors order: [ 'first input (slow)', 'second input (fast)' ]

MDN documents that fulfilling the result does not cancel the remaining operations, that every input is marked as handled, and that an empty iterable produces an already rejected promise. In the table, C still wrote at about 250 ms after Promise.any() had settled with B's value.

Sequential await is not a combinator, but it is the other way to avoid the problem. It stops later operations from ever starting, so after A fails there is no B or C to worry about. This only holds when you start each operation after the previous await has finished. If you create all the promises first and then await them one by one, everything has already started. Sequential execution does not make failure safer in general. Anything that already ran stays done, and the total time becomes the sum of the operation times instead of the longest one. It is the right choice when operations depend on each other, or when running them together would be wrong for the target system. It is the wrong choice when they are independent and the user is waiting.

How to cancel the remaining requests when Promise.all() fails

Promises have no cancellation mechanism of their own. The platform's answer is cooperative cancellation with AbortController. You create a controller, hand its signal to the operations, and call abort() when you want them to stop. The signal only communicates. As the MDN page for AbortSignal puts it for promise-based APIs, an operation should react to the abort by rejecting its unsettled promise with the signal's reason. Whether it does is up to the operation.

There is a design consequence. In the common pattern, the functions that produce the promises have already been called before Promise.all() receives them, so there is no moment at which you could give them a signal. A cancellation-aware version has to take functions that start the work and accept a signal. That also lets it skip operations that have not started yet when something has already failed.

The repository contains a teaching implementation, runAllOrAbort. Validation and comments are trimmed here, and the full file is in the repo.

export class SiblingFailedError extends Error {
  constructor(cause) {
    super("Aborted because another task in the group failed", { cause });
    this.name = "SiblingFailedError";
  }
}

export class GroupFailedError extends Error {
  constructor(cause, { outcomes, timedOut, whenSettled }) {
    super("A task in the group failed", { cause });
    this.name = "GroupFailedError";
    this.outcomes = outcomes;
    this.timedOut = timedOut;
    this.whenSettled = whenSettled;
  }
}

const isAbortInduced = (reason, signal) =>
  signal.aborted &&
  (reason === signal.reason || reason?.cause === signal.reason);

export async function runAllOrAbort(tasks, { settleTimeoutMs = 5000 } = {}) {
  const controller = new AbortController();
  const { signal } = controller;
  const outcomes = tasks.map(() => ({ status: "not-started" }));
  const snapshot = () => outcomes.map((o) => ({ ...o }));

  let firstFailure = null;
  let markFailed;
  const failed = new Promise((resolve) => {
    markFailed = resolve;
  });

  const running = tasks.map(async (task, i) => {
    if (signal.aborted) return;
    outcomes[i] = { status: "pending" };
    try {
      const value = await task(signal);
      outcomes[i] = {
        status: "fulfilled",
        value,
        observedAfterAbort: signal.aborted,
      };
    } catch (reason) {
      const abortInduced = isAbortInduced(reason, signal);
      outcomes[i] = {
        status: "rejected",
        reason,
        abortInduced,
        observedAfterAbort: signal.aborted,
      };
      if (!abortInduced && !firstFailure) {
        firstFailure = { reason };
        controller.abort(new SiblingFailedError(reason));
        markFailed();
      }
    }
  });

  const allSettled = Promise.all(running).then(() => "settled");

  await Promise.race([allSettled, failed]);
  if (!firstFailure) return outcomes.map((o) => o.value);

  let timer;
  const deadline = new Promise((resolve) => {
    timer = setTimeout(resolve, settleTimeoutMs, "timeout");
  });
  const result = await Promise.race([allSettled, deadline]);
  clearTimeout(timer);

  throw new GroupFailedError(firstFailure.reason, {
    outcomes: snapshot(),
    timedOut: result === "timeout",
    whenSettled: allSettled.then(snapshot),
  });
}

The design choices worth noticing.

The first genuine failure triggers the abort. The abort reason is a SiblingFailedError that wraps the original error, so a task can tell why it was stopped.
A failure is separated from an abort. A rejection counts as abort-induced only when it is the abort reason itself or carries it as its cause. The name AbortError alone is not evidence, because a task can fail on its own with an error of that name.
The caller gets the original error. GroupFailedError.cause is the first genuine failure, along with a snapshot of every task's status.
Waiting is bounded. After aborting, the helper waits up to settleTimeoutMs for started tasks to settle, then throws anyway. whenSettled resolves later with the final outcomes.
Promise.all() is safe inside it. Every entry in running catches its own errors, so that aggregate never rejects.

The fourth script drives it with five tasks. E finishes before the failure. A fails at about 50 ms. B uses Node's timers/promises setTimeout with a signal, an API that supports abort. C is a hand-written timer that honours the signal. D ignores the signal entirely. Logging is trimmed here.

const tasks = [
  // E: finishes before the failure
  async () => {
    await sleep(20);
    effect("E");
    return "E ok";
  },
  // A: the genuine failure
  async () => {
    await sleep(50);
    throw new Error("A failed");
  },
  // B: a real API that supports AbortSignal
  async (signal) => {
    const v = await timersSleep(150, "B ok", { signal });
    effect("B");
    return v;
  },
  // C: hand-written, honours the signal
  (signal) =>
    new Promise((resolve, reject) => {
      if (signal.aborted) return reject(signal.reason);
      const t = setTimeout(() => {
        effect("C");
        resolve("C ok");
      }, 250);
      signal.addEventListener(
        "abort",
        () => {
          clearTimeout(t);
          reject(signal.reason);
        },
        { once: true },
      );
    }),
  // D: ignores the signal entirely
  async () => {
    await sleep(250);
    effect("D");
    return "D ok";
  },
];

Task C is deliberately minimal. In real code, also remove the abort listener when the timer completes normally, as MDN advises for abortable APIs, so a long-lived signal does not keep it alive. { once: true } only removes the listener if the signal actually aborts.

First run, waiting for every task to settle after the abort (Node.js 22.23.4). The script also prints status tables, which are shown separately below.

   21 ms  E side effect performed
   51 ms  A throws
   52 ms  C received abort and cleared its timer
   52 ms  B rejected: name=AbortError, cause is signal.reason: true
  251 ms  D side effect performed
  252 ms  runAllOrAbort threw: cause="A failed"

Side effects that happened in total: E, D

Task	Status when the helper threw	Abort-induced	Observed after abort
E	fulfilled	-	false
A	rejected	false	false
B	rejected	true	true
C	rejected	true	true
D	fulfilled	-	true

A dash means the field does not apply. Four different things happened, and they are easy to blur together.

E finished before anyone asked for cancellation. The abort could not undo it, and its side effect stands.
B and C received the signal and stopped. Their 150 ms and 250 ms timers never produced a side effect. This is cancellation working, because each of them cooperates.
D received the signal too, because it was passed to every task, and ignored it. It ran to completion and wrote at about 251 ms. The abort request did not stop it.
observedAfterAbort is true for D because the helper saw D settle after the abort had been requested. It records what the helper saw, not when the work physically finished.

The second run uses a settleTimeoutMs of 100. The helper aborts, waits 100 ms and then throws without waiting for D. These are the log lines in time order.

   21 ms  E side effect performed
   50 ms  A throws
   51 ms  C received abort and cleared its timer
   51 ms  B rejected: name=AbortError, cause is signal.reason: true
  152 ms  runAllOrAbort threw: cause="A failed"
  251 ms  D side effect performed

Side effects that happened in total: E, D

When the error reached the caller, D's status was pending. That is all the caller could know. Then D wrote at about 250 ms anyway, after the error had been reported. This is the difference between three things that people often treat as one. Stopping the caller's wait (the helper threw), requesting cancellation (the abort), and actually terminating the work (something only the operation itself can do).

One note on the output above. The line B rejected: name=AbortError, cause is signal.reason: true is an observation from Node.js 22.23.4. Node's timers documentation says the promise returned by the timer rejects with an AbortError when its signal aborts, and the section does not mention a cause. The helper accepts both shapes (rejecting with signal.reason itself, or an error that carries it as cause) so it does not depend on one runtime detail. If you adapt it, test it against the APIs you actually call. fetch was not tested here.

Which approach to choose: a decision table

There is no single right answer, because the right answer depends on what the operations do and what a failure means. These five questions get you most of the way. Do you need every result? Do you need to hear about every failure? Do the operations have effects outside the promise? Do they support cancellation? Does one depend on another?

Situation	Use	What you accept
All operations must succeed, and you do not need to stop the others automatically	`Promise.all()`	The others keep running after a failure. Fine for cheap or idempotent work, risky for expensive or side-effecting work. No rollback
Every outcome matters, because you report, retry or clean up per item	`Promise.allSettled()`	You wait for the slowest operation. No fail-fast
The first success is enough, such as mirrors or fallbacks	`Promise.any()`	The losers keep running unless you cancel them. If all fail, you get an `AggregateError` with reasons in input order
Remaining work is expensive or useless after a failure, and the operations accept a signal	Concurrent tasks with a shared `AbortController`	Tasks that ignore the signal keep running, finished work is not undone, and you need to treat abort errors differently from real ones
Operations depend on each other, or concurrency would be wrong for the target	Sequential `await`	Total time is the sum of the parts. Earlier completed steps still stand if a later one fails

Three rules of thumb sit under the table.

Let the rest finish when the work is independent, cheap and still useful. Prefetching three panels of a dashboard is a good example. If one panel fails, the other two results are worth having, and Promise.allSettled() lets you render them.

Request cancellation when the remaining work is expensive or its result is now pointless. Large downloads, heavy computations and long-polling requests are the classic cases. Do it only through APIs that accept a signal, and do not describe it to yourself as stopped until the operation says so.

When cancellation is unsupported, change what you promise. You cannot abort arbitrary JavaScript work from outside it. What you can do is stop waiting, ignore the late result, and make the effect safe to repeat. Mark the operation's state in your own code (for example, a request id that the UI checks before it renders a late response), and use idempotency keys for writes, as the next section shows.

Retrying after Promise.all() fails: why repeating the whole group can duplicate writes

Back to the Save all button. The fifth script reproduces it without a database or a network. An in-memory ledger stands in for any destination where a write has an effect. Three writes run together, and w3 fails once.

function createLedger() {
  const rows = [];
  const seen = new Set();
  let failNextFor = new Set();
  return {
    rows,
    failOnce: (id) => failNextFor.add(id),
    // Without an idempotency key, every call appends a row.
    async write(id, key) {
      await sleep(id === "w3" ? 20 : 60);
      if (failNextFor.has(id)) {
        failNextFor.delete(id);
        throw new Error(`${id} failed`);
      }
      if (key && seen.has(key)) return `${id} (duplicate ignored)`;
      if (key) seen.add(key);
      rows.push(id);
      return id;
    },
  };
}

The first scenario is what the button in the opening example does. It runs Promise.all() on the three writes, and on failure runs the whole group again.

attempt 1 rejected: w3 failed
ledger after attempt 1: [ 'w1', 'w2' ]
ledger after naive full retry: [ 'w1', 'w2', 'w3', 'w1', 'w2' ]

w3 failed first, so the aggregate rejected at about 20 ms. w1 and w2 were already in flight and landed afterwards, which is why the ledger holds them after attempt 1 even though the attempt "failed". The retry then wrote all three again. w1 and w2 now exist twice.

Two other approaches fix it, and they work differently. Giving each write a stable key derived from the logical operation, not from the attempt, lets the receiver drop repeats. Collecting outcomes with Promise.allSettled() lets you retry only what failed.

// Scenario 2: retry the whole group, but every write carries a stable key
const attempt = () =>
  Promise.all(ids.map((id) => ledger.write(id, `order-42:${id}`)));

// Scenario 3: collect outcomes, retry only the failures
const first = await Promise.allSettled(ids.map((id) => ledger.write(id)));
const failedIds = ids.filter((_, i) => first[i].status === "rejected");
await Promise.all(failedIds.map((id) => ledger.write(id)));

ledger after full retry with idempotency keys: [ 'w1', 'w2', 'w3' ]
failed after first pass: [ 'w3' ]
ledger after retrying only failures: [ 'w1', 'w2', 'w3' ]

Both end with each write exactly once. The third approach has a trap, though, which is the fourth scenario. A rejected call does not prove the write failed. A timeout can reject the caller while the write still commits on the other side. The script injects that case. The write commits, but the caller only sees a timeout.

Simulated lost response, the write commits but the caller sees a timeout
  attempt 1 rejected (w1 timed out waiting for the response)
  after a retry without an idempotency key, ledger = [ 'w1', 'w1' ]
  attempt 1 rejected (w1 timed out waiting for the response)
  after a retry with an idempotency key, ledger = [ 'w1' ]

That last scenario is simulated, not measured. It shows the logic, not how often a real system loses a response.

What to take from it.

Retrying only the failures is safe only when a failure is known to mean "not applied." A validation error usually does. A timeout does not.
Idempotency keys are the safety net, and the receiving service has to enforce them. The Set in the script lives inside one process. Real enforcement has to survive restarts, multiple servers and concurrent requests, so it belongs in the service or database that accepts the write.
Do not start a retry while attempt one is still in flight. After a failure, work from the first attempt may still be landing, as w1 and w2 did. If you request cancellation, wait for whenSettled (or accept the risk knowingly) before retrying. The overlap case was not run as a separate script. It follows directly from the lifecycle shown earlier.
A cancelled operation may still have committed. Aborting after the request has been sent does not tell you whether the other side applied it.

Limitations

Some of what I wrote here is promised by the JavaScript spec, so it holds in every engine. The rest is just what I saw when I ran the scripts in Node.js, and another runtime could do something different. Here is how I split the two.

From the specification and MDN. These come from the documentation, not from my runs. The aggregate settles on the first rejection, nothing gets cancelled, handlers are attached to every input, Promise.any() lists AggregateError reasons in input order, and promise-based APIs are expected to reject with the abort reason.
Observed on Node.js only. I only saw these on Node.js, namely the unhandledRejection counts, the exit codes, and the cause on the AbortError from timers/promises. They are runtime behaviour, so they could differ elsewhere. I ran the scripts on Linux with Node.js 22.23.4, 24.22.2 and 26.13.0. The tests and all five scripts also passed on Windows with Node.js 22.22.2, and that run printed the same events in the same order, line for line, once I ignored the elapsed milliseconds. Windows was slower. I did not test any other versions or operating systems, and the output blocks in this article come from one Linux run on 22.23.4.
I did not test browsers. MDN documents that Promise.all() marks its inputs as handled and that later rejections do not trigger unhandledrejection. Treat that as MDN's claim, since my runs did not verify it.
Only one real cancellable API got tested. That was the timer from timers/promises, plus a hand-written task. I did not test fetch, streams, file APIs or database drivers, so please do not assume they behave like the timer. I did test what an aborted request does to a node-postgres query in an earlier post.
I did not look at Promise.race(). It has the same shape of problem, with its own questions about timers and cleanup.
The operations are simulated with timers. The timings are approximate, and the order of events is what I am claiming. I ran each script ten times and compared the full output, ignoring the elapsed milliseconds. Every script produced one distinct output, on Linux and also on Windows with Node.js 22.22.2.
runAllOrAbort is there to teach the pattern, not to replace a concurrency library. It cannot stop a task that ignores the signal, it cannot undo work that already finished, and whenSettled stays pending if a started task never settles. The failure it reports is the first one it saw, which is not always the one that physically happened first. settleTimeoutMs has to be an integer from 1 to 2147483647. Anything else throws a RangeError, because setTimeout() normalizes out-of-range delays to 1 ms.
The ledger in the retry script lives in memory. Real idempotency has to be enforced by the service that receives the write. The lost response in the last scenario is injected, not measured.

Reproduce the examples

Everything above comes from the promise-all-rejection-and-cancellation repository. It is plain Node.js with no dependencies, no network access, no servers and no database. It needs Node.js 22 or newer.

git clone https://github.com/shubhrapokhariya/promise-all-rejection-and-cancellation.git
cd promise-all-rejection-and-cancellation
npm run verify   # helper tests, then all five scripts
npm run repeat   # run each script 10 times and compare the full output, takes about a minute
npm test         # helper tests only
node 01-lifecycle.mjs   # or any single script, 01 to 05

File	What it shows
`01-lifecycle.mjs`	The aggregate rejects first, the other inputs still settle, and a side effect still happens afterwards
`02-later-rejections.mjs`	Later input rejections raise no `unhandledRejection` event in Node, and a rejection nobody handles does
`03-combinators.mjs`	`all`, `allSettled`, `any` and sequential `await` on the same operations
`04-cancellation.mjs`	A shared `AbortController`, tasks that honour the signal, one that ignores it, and giving up the wait
`05-partial-failure.mjs`	Full retry versus idempotency keys versus retrying only failures, plus a simulated lost response
`lib/run-all.mjs`	The `runAllOrAbort` helper, covered by 19 tests in `test/run-all.test.mjs`

Each line of a timeline starts with elapsed milliseconds. Treat the order of events as the result, since the exact numbers change from run to run. The repository also includes a GitHub Actions workflow that runs npm run verify on Node.js 22, 24 and 26.

Practical takeaway

A rejected Promise.all() ends your wait. It does not end the work. Four facts that look like one are actually separate. The promise rejected, cancellation was requested, the operation stopped, and the effect happened. Your code can observe the first two directly. The last two are known only if the operation tells you.

Before wrapping side-effecting work in Promise.all(), ask three questions. Which of these operations already has an effect outside the promise? Does each one accept a signal and actually honour it? Is the effect safe to repeat if the whole thing runs again? If you cannot answer the third question with yes, fix that first. Cancellation reduces waste. Idempotency prevents duplicate writes.

The only real cancellable API I tested here was Node's timer, and I covered database drivers in an earlier post, so I am curious about everything else. Has an HTTP client, SDK or queue ever kept working after its AbortSignal fired on you? Tell me which one and what you saw in the comments.

Sources

Official documentation and specification pages, checked on 10 November 2026.

If Diwali Had a Git Commit History, Mine Would Be Full of Last-Minute Changes

Shubhra Pokhariya — Thu, 05 Nov 2026 14:22:19 +0000

Diwali, the Indian festival of lights, is approaching, and my home is slowly turning into a little creative workshop. 🪔

There are decorations to make, rangoli designs to finish, diyas to arrange, sweets to prepare, and a growing list of food requests from family members.

Looking at all these preparations, my developer brain couldn't resist imagining what the Git history of Diwali would look like. 😄

But before getting to that, there's one little tradition I never want to skip.

The toran I never skip

I can never resist the beautiful, creative torans I see in the market. There are so many lovely designs! But alongside those, I still love making a traditional toran, a door hanging made with fresh marigold flowers and mango leaves.

It takes me straight back to my childhood, when my grandmother would make them and I would sit beside her, helping put the flowers and leaves together.

I don't remember when this became such a special part of Diwali for me. Perhaps I didn't think much about it back then. It was just something we did together before the festival.

Now, whenever Diwali approaches, I find myself wanting to recreate that little experience. I think I miss not just making the toran, but those moments spent with her.

Rangoli, diyas and a little experimenting

And then there's rangoli!

I'm no rangoli expert, but I absolutely love making these colourful floor patterns with coloured powders and flowers. I enjoy sitting down to experiment with different designs and watching the patterns come together. Sometimes the idea in my head and the rangoli on the floor are two very different things, but that's part of the fun.

This time, I've also been experimenting with pompoms, pearls, little mirror pieces and cardboard to add creative details to my decorations.

I've been making decorative diyas (traditional oil lamps) too, and putting together a little urli arrangement using a traditional decorative bowl filled with water, flowers and diyas.

Every design starts with an idea. Sometimes I change the arrangement halfway through, add another detail, or discover that something looks better a little differently.

The Diwali commit history

If these preparations had version control, mine would probably look something like this:

commit 01: init: started Diwali preparations

commit 02: add: marigold and mango-leaf toran

commit 03: feature: handmade decorative diyas

commit 04: design: created a new rangoli layout

commit 05: add: pearls, pompoms and mirror pieces

commit 06: update: added fresh flowers to the design

commit 07: feature: completed the festive urli

commit 08: polish: rearranged decorations until everything felt right

Unexpected changes

Of course, no project is complete without a few unexpected changes.

hotfix: ran out of flowers halfway through
bug: rangoli design looks different from the original sketch
change-request: family wants one more decoration

And then there's the kitchen

And we haven't even reached the kitchen!

Diwali preparations in our family also involve homemade sweets and special festive food. The interesting part is that everyone has their own favourite.

One person requests a particular sweet, another remembers a snack they loved last year, and someone else suddenly comes up with a new suggestion.

So the menu becomes a little requirements document of its own.

feature: prepare everyone's favourite festive food
issue: ingredient missing
priority: high
hotfix: one more trip to the market
review: family tasting session
feedback: can we make a little more?

I think the family tasting session might be the most important code review of the entire project. And unlike software reviews, nobody is particularly interested in keeping their feedback short! 😂

The joy of making things by hand

Jokes aside, I really do enjoy all of this.

As developers, we're often looking for ways to build faster, reuse components, automate repetitive tasks and make our work more efficient. I love that side of development too.

But there's something satisfying about making things by hand, without worrying too much about how long they take or whether the result is perfect.

You start with an idea, try it out, change a few things, sometimes get it wrong, and eventually end up with something that makes you smile.

Perhaps that's why I enjoy these preparations so much. The finished decorations look good, but the time spent making them, especially when it brings back childhood memories, is just as special.

Every family has its own traditions

I suppose every family has its own version of these little traditions. Mine just happens to involve marigolds and mango leaves.

I'm curious, is there something you always make or do for a celebration that wouldn't feel quite the same without it?

Maybe it's a recipe from your grandmother, a decoration you make every year, or something you loved doing as a child and still look forward to today.

I'd love to hear about it. I always enjoy discovering the little traditions people carry with them, especially the ones that come with childhood memories.

Happy Diwali, everyone! Wishing you a season full of creativity, warmth, good food and beautiful memories. ❤️

Does AbortSignal Cancel a Node.js Database Query? 4 Drivers Tested

Shubhra Pokhariya — Mon, 02 Nov 2026 11:43:10 +0000

I let 12 Node.js clients walk away from their database queries on a 4-connection pool. The abandoned queries kept every connection busy for about 6 seconds, and the first healthy select 1 waited 5.7 seconds behind them. Passing an AbortSignal to the query did nothing for pg, mysql2 or mariadb, and postgres.js 3.4.9 has no such option.

This is the second post in my series on cancellation in Node.js. In the first, I tested whether aborting a request stops the work behind it (read it here). With node-postgres it doesn't. The query ran to completion, and pg_cancel_backend was what stopped it. That left two questions. Do other drivers behave differently? And what does a pile of abandoned queries do to everyone else who shares the pool?

I built a harness to answer both, and the postgres.js results did not go the way I expected. My first postgres.js starvation run came back with four cancelled promises that never settled, and my harness threw the run away as invalid. I changed it to count unsettled requests instead of discarding them, then cut the problem down to a script that does not use the harness at all. The result held. Then postgres.js 4.0.0 came out with a new query.signal(), so I ran everything again against both versions.

Both tests cover pg, postgres.js 3.4.9 and 4.0.0, mysql2 and the mariadb connector, against PostgreSQL 18.6 and MySQL 8.4.13.

TL;DR

Of the five driver versions I tested, only postgres.js 4.0.0 reads an AbortSignal on a query (query.signal()). pg 8.23.1, mysql2 3.24.6, mariadb 3.5.4 and postgres.js 3.4.9 do not. I searched the installed packages, then checked every result against the database, not against what the driver reported.
In the naive lock pile-up test, 12 abandoned requests kept a 4-connection pool busy. The first healthy select 1 waited about 5.7 seconds, and the database showed about 24 connection-seconds of tagged query activity.
Cancelling the requests that were running and skipping the ones that had not started kept the first healthy query at 1 to 107 ms on Windows and 0 to 1 ms on Linux with pg, mysql2 and mariadb. postgres.js 4.0.0 with query.signal() did it in 1 to 3 ms, in a test where every query was blocked on the same lock. A fast query already sent behind a running one was not rejected at the abort, though (see the postgres.js section).
postgres.js 3.4.9 has a trap. With a warm pool, 4 of the 12 cancelled promises never settled, in every run I made, on Windows and on Linux. How much that hurt other queries varied from run to run. I did not reproduce the unsettled promises on 4.0.0 in any scenario I tested. On 3.x, reserving a connection per request avoided them in my test.

Here is what to do for each driver, based on these tests.

Driver	Reads an `AbortSignal`?	What stopped the query
pg 8.23.1	No	`pg_cancel_backend()` from a second connection
mysql2 3.24.6	No	`KILL QUERY` from a second connection
mariadb 3.5.4	No	`KILL QUERY` from a second connection
postgres.js 3.4.9	No such option	`query.cancel()`, but 4 of 12 promises never settled with a warm pool. A reserved connection per request avoided that
postgres.js 4.0.0	Yes, `query.signal()`	`query.signal(signal)`. All 12 queries in my lock test were rejected, but a fast query already sent behind a running one was not rejected at the abort

How I measured it

Verdicts and busy-connection counts come from the database side. A separate observer connection polls pg_stat_activity (PostgreSQL) or SHOW FULL PROCESSLIST (MySQL) for a query tagged with a unique comment. It polls every 50 ms in test 1 and is sampled every 100 ms in test 2, so those timings have about that much resolution. Wait times and whether a promise settled are client-side timers, because that is where they happen. I never rely on what a driver says about itself.

I ran everything on Windows 10 with Docker Desktop (WSL 2), Node.js 22.22.2, PostgreSQL 18.6 and MySQL 8.4.13. All connections are direct and on localhost. I also ran both tests once on each of Node.js 22.23.4 and 24.22.1 on GitHub Actions, on an Ubuntu runner against the same PostgreSQL 18.6 and MySQL 8.4.13 images. Those runs are on the Actions tab of the repo, and run #1 is the one quoted here.

I ran two tests and two small reproduction scripts. The code is in the repo, node-db-abort-matrix.

Test 1: does passing an AbortSignal cancel a database query?

A query sleeps for 3 seconds on the server. The client waits until the database shows it running, aborts 500 ms later, and immediately sends select 1 through the same one-connection pool. Each driver runs up to three ways: no cancellation, the signal passed as a query option (where the driver has one), and the driver's own cancel route. A query counts as stopped if the database is idle within 1 second of the abort.

pg, postgres.js 3.4.9, mysql2 and mariadb ran this nine times on Windows, and postgres.js 4.0.0 ran three times.

Driver	Version	Passing a signal	Cancel that worked	Time to stop after cancel
pg	8.23.1	Ignored. Database idle 2.5 s after the abort	`pg_cancel_backend()` from a second connection	4 to 136 ms
postgres.js	3.4.9	No such option	`query.cancel()`	61 to 88 ms
postgres.js	4.0.0	Honored. `query.signal(signal)` stopped the query, database idle 64 to 88 ms after the abort	`query.cancel()`	64 to 65 ms
mysql2	3.24.6	Ignored. Database idle 2.5 s after the abort	`KILL QUERY` from a second connection	3 to 116 ms, one run 651 ms
mariadb	3.5.4	Ignored. Database idle 2.5 s after the abort	`KILL QUERY` from a second connection	3 to 71 ms

All verdicts were identical in every Windows run. Of the 39 cancel runs, 38 stopped within 136 ms. One mysql2 run took 651 ms, and I read nothing into a single outlier. The two Linux runs, one per Node version, gave the same verdicts for all five driver versions. postgres.js 4.0.0's .signal() stopped the query on both, with the database idle 54 ms after the abort.

When the signal was ignored, the select 1 behind it waited 2.4 to 2.5 seconds, because the connection was still running the sleep.

I also searched the installed packages for signal and abort in their JavaScript, TypeScript and Markdown files. In pg, mysql2 and mariadb, the only hits were error-code tables, comments and a pool message. postgres.js 3.4.9 and pg-pool (3.14.0) had no hits at all. For mariadb I passed both signal and abortSignal, so the result does not depend on guessing the option name. postgres.js 4.0.0 is the exception, and its release notes list .signal(abortSignal) as new.

One MySQL detail to know. When KILL QUERY interrupts SELECT SLEEP(n), MySQL returns 1 and no error, so the promise resolves early instead of rejecting. A killed lock wait behaves differently. It rejected with ER_QUERY_INTERRUPTED in both mysql2 and mariadb (see test 2).

Test 2: how abandoned requests starve a Node.js connection pool

This is the incident that makes teams care. One session holds a row lock for 6 seconds. Twelve requests that need that row go through a pool of 4 connections, and every client gives up 200 ms later. Starting 300 ms in, a healthy select 1 is sent every 100 ms through the same pool. A healthy query counts as slow if it takes longer than 500 ms or fails.

Each driver runs up to three times:

naive: nothing notices the clients left.
signal: the signal is passed to the driver and nothing else is done. This is what you get if you trust the option.
cancel-aware: for pg, mysql2 and mariadb, a request that has not started is skipped, and one that is running is cancelled with the route from test 1. The postgres.js adapters send all 12 queries to the pool at once and cancel all 12, so nothing is skipped there.

On Windows I ran naive and cancel-aware six times and the signal mode three times. postgres.js 4.0.0 ran three times in every mode. The ranges below are across those runs.

Driver	Mode	First healthy query waited	Slow healthy queries (of about 58)	Connection-seconds held	Abandoned: rejected / finished or skipped / never settled
pg	naive	5709 to 5743 ms	49	23.7 to 24.0	0 / 12 / 0
pg	signal	5731 to 5743 ms	49 to 50	24.0 to 24.1	0 / 12 / 0
pg	cancel-aware	2 to 6 ms	0	0.4 to 0.8	4 / 8 / 0
postgres.js 3.4.9	naive	5728 to 5757 ms	48 to 49	23.5 to 23.8	0 / 12 / 0
postgres.js 3.4.9	cancel-aware	5704 to 5713 ms	2 to 48	12.7 to 24.1	8 / 0 / 4
postgres.js 4.0.0	naive	5714 to 5761 ms	48 to 49	23.6 to 23.7	0 / 12 / 0
postgres.js 4.0.0	signal	2 to 3 ms	0	1.4	12 / 0 / 0
postgres.js 4.0.0	cancel-aware	2 to 3 ms	0	1.3 to 1.4	12 / 0 / 0
mysql2	naive	5702 to 5818 ms	47 to 50	23.6 to 24.5	0 / 12 / 0
mysql2	signal	5707 to 5719 ms	48 to 49	23.6 to 24.1	0 / 12 / 0
mysql2	cancel-aware	2 to 107 ms	0	0.6 to 1.4	4 / 8 / 0
mariadb	naive	5707 to 5735 ms	48 to 49	23.7 to 23.9	0 / 12 / 0
mariadb	signal	5692 to 5711 ms	47 to 48	23.5 to 23.6	0 / 12 / 0
mariadb	cancel-aware	1 to 5 ms	0	0.4 to 0.9	4 / 8 / 0

Connection-seconds is the number of the test's tagged queries that the database shows as active, summed over time and sampled every 100 ms. It is not how long a client library considers a connection checked out.

A few notes on reading the table.

The naive numbers are nearly identical across drivers because the pool and the lock decide them, not the driver. Nobody gets a connection until the lock holder lets go. The 5.7 seconds is my 6-second lock minus the 300 ms before the first probe. A longer lock means a longer stall.
The signal rows for pg, mysql2 and mariadb look like naive, because those drivers ignore the option. Passing { signal } and walking away fixed nothing.
In cancel-aware mode for pg, mysql2 and mariadb, 4 requests were running when the clients left, so they needed a cancel. The other 8 were still waiting for a connection and never needed to run. Skipping them is half of the saving, and a cancel that fires before the statement starts does nothing, so check signal.aborted after you get the connection.
The postgres.js adapters have no "not started" state for my code to check, so they send all 12 queries and call query.cancel() on all 12 after 200 ms. On 4.0.0 all 12 were rejected with 57014. On 3.4.9, 8 were rejected and 4 never settled.
Killed lock waits rejected with 57014 on PostgreSQL and ER_QUERY_INTERRUPTED on MySQL, so a cancel works on a blocked query as well as a running one.

The Linux runs, one on Node 22 and one on Node 24, show the same pattern. The naive and signal rows for pg, mysql2 and mariadb had the first healthy query waiting 5700 to 5705 ms. Cancel-aware took 0 to 1 ms for those three drivers, with 0.5 to 0.7 connection-seconds held. postgres.js 4.0.0 took 1 ms in both its signal and cancel-aware modes, with 0.7 to 1.3 connection-seconds held.

The postgres.js 3.4.9 cancel-aware row needs a closer look. Exactly 4 promises never settled in every run I made, six on Windows and one on each Node version on Linux. The other numbers moved a lot. Across the Windows runs, between 2 and 48 healthy queries were slow, and both Linux runs gave 2 slow out of the 62 healthy queries each run sent. The first healthy query waited about 5.7 seconds in every Windows run and in the Node 24 run on Linux, but only 1 ms in the Node 22 run. I have not traced why. Treat the unsettled promises as the result and the stall as timing dependent.

postgres.js 3.4.9: queries that never settle, and what 4.0.0 changed

In test 2, postgres.js 3.4.9 is the exception. In every run, 4 abandoned promises never settled. In my Windows runs the first healthy query also waited 5.7 seconds, and the paragraph above shows how much that part varied.

I reduced it to a script that does not use my harness. Twelve queries wait on a row lock, the pool has 4 connections, and query.cancel() is called on all of them after 200 ms. I ran it four times on 3.4.9 and once on 4.0.0.

Scenario	3.4.9 before the cancel	3.4.9 result	4.0.0 result
Cold pool, 12 queries	4 running, 8 queued inside the pool	all 12 rejected with `57014`	all 12 rejected with `57014`
Warm pool, 12 queries	4 running, 8 already sent and waiting behind a running query	4 never settled (always queries 4 to 7)	all 12 rejected
Warm pool, 8 queries	4 running, 4 sent and waiting	all 8 rejected	all 8 rejected
Warm pool, 12 queries, `max_pipeline: 1`	4 running, 4 sent, 4 queued	all 12 rejected	all 12 rejected
Warm pool, 12 requests, one reserved connection each	4 running, 8 waiting for a connection	4 rejected, 8 skipped, none stuck	4 rejected, 8 skipped, none stuck

The 3.4.9 runs all gave the same result as the table. How the cold pool looks just before the cancel depends on how fast connections open. It is usually 4 running and 8 queued, and once, on a slow start, all 12 were still queued. The verdict was the same. 4.0.0 schedules queries differently, so two of its scenarios start from a different state. The cold pool already had 8 queries sent behind the 4 running ones, and with max_pipeline: 1 the 8 extra queries waited inside the pool. Nothing was left unsettled in any scenario.

On 3.4.9 the problem needs a warm pool, and the stuck requests were among those already sent to a connection behind a running query. Not every request in that state got stuck, though. Four of the 8 did. With one waiting query per connection, nothing got stuck.

Issue #1252 in the postgres.js repo describes what I measured. Cancelling a query that is pipelined behind another one but has not started leaves the cancelled query unsettled, and the next query on that connection can get the wrong result. A comment in the thread points at the loop in ReadyForQuery in connection.js (lines 573 and 574 in 3.4.9). It was closed by a v4 commit that shipped in 4.0.0.

The issue also describes a worse effect. The next query on that connection can receive the cancelled statement's rows. My harness counted failed probes as slow but did not check what the probes returned, so I can't say whether that happened in my runs.

4.0.0 also adds query.signal(signal). Per its release notes, aborting rejects a query that is still waiting and cancels one that is running. That is consistent with the table above, where all 12 queries were blocked on the same lock and all 12 were rejected. The next section checks what "waiting" means.

When .signal() rejects a query, and when it does not

"Waiting" can mean two different things in postgres.js. A query can wait in the pool's queue, or it can already be sent to a connection behind a running query. I wrote a second script to tell them apart (src/repro-postgresjs4-signal.js). The pool has one connection. A slow query runs for 1.5 seconds, a second query is behind it, and the second query's signal is aborted 200 ms in. I ran four cases once on Windows against PostgreSQL 18.6.

Case	Second query	Result
A: sent behind the running query (default), fast	`select 'fast'`	resolved normally, 1668 ms after the start, so the abort did not reject it
B: sent behind the running query (default), slow	`select pg_sleep(5)`	rejected with `57014` at 1532 ms, when the query ahead had finished
C: queued in the pool (`max_pipeline: 1`), fast	`select 'fast'`	rejected with `57014` at 223 ms
D: queued in the pool (`max_pipeline: 1`), slow	`select pg_sleep(5)`	rejected with `57014` at 220 ms

So .signal() rejected a query promptly while it was still queued inside the pool. A query that had already been sent behind a running one, which is the default, was not rejected at the abort. A slow one was rejected once the query ahead finished, and a fast one ran to completion and resolved normally. In the lock test all 12 queries were blocked on the same lock, which fits each one being cancelled when its turn came, but I did not trace that. I did not test writes. This is one run of mine, so read the order of events and not the milliseconds.

Every cancel in postgres.js is best effort, including on 4.0.0. Its README explains that a cancel opens a new connection and sends a protocol-level cancel request, so there is no guarantee the query stops, and because of race conditions it can end up cancelling a different query. The 4.0.0 release notes say the same. A cancel that reaches the server just as its query finishes can still stop the next query on that connection. I did not test for that race.

If you are on postgres.js 3.x and cancel bursts of queries, reserving a connection per request is what I would use, and it is the second postgres.js recipe below. If you can move to 4.0.0, .signal() is simpler. It is a major release with behavior changes (parameter typing, supported runtimes, transaction handling), so read its upgrade guide first.

How to cancel a database query in Node.js when the driver ignores AbortSignal

The shape is the same everywhere. Take a connection, check that the client is still there, remember which backend you are on, and cancel from somewhere else if the client leaves. These follow the adapters in the repo, which are what I measured. There are two differences. The repo sends cancels over a single dedicated connection, one at a time, and the node-postgres version below uses a small pool for that. And the repo ignores a failed cancel, because a cancel that did not work shows up in the measurement as a query that kept running, while the recipes below log it, which is what you want in production.

node-postgres

// cancel(pid) sends pg_cancel_backend from a small pool kept only for cancels
const cancel = (pid) => cancelPool.query("select pg_cancel_backend($1)", [pid]);

export async function cancellableQuery(pool, text, params, signal) {
  const client = await pool.connect();
  let cancelling = Promise.resolve();
  try {
    if (signal.aborted) return null; // the client left while we waited for a connection
    const { rows } = await client.query("select pg_backend_pid() as pid");
    const pid = rows[0].pid;
    if (signal.aborted) return null;
    const onAbort = () => {
      cancelling = cancel(pid).catch((err) =>
        console.error("cancel failed", err),
      );
    };
    signal.addEventListener("abort", onAbort, { once: true });
    try {
      return await client.query(text, params);
    } finally {
      signal.removeEventListener("abort", onAbort);
      await cancelling;
    }
  } finally {
    client.release();
  }
}

mysql2 (the mariadb connector needs two changes. Its query() returns the rows directly, so write const rows = await conn.query(...) and not const [rows] = ..., and connection_id() comes back as a BigInt, so keep the Number())

// killConn is a separate connection used only for KILL QUERY
export async function cancellableQuery(pool, killConn, sql, signal) {
  const conn = await pool.getConnection();
  let killing = Promise.resolve();
  try {
    const [rows] = await conn.query("select connection_id() as id");
    const threadId = Number(rows[0].id);
    if (signal.aborted) return null; // the client left while we waited for a connection
    const onAbort = () => {
      killing = killConn
        .query(`KILL QUERY ${threadId}`)
        .catch((err) => console.error("cancel failed", err));
    };
    signal.addEventListener("abort", onAbort, { once: true });
    try {
      return await conn.query(sql);
    } finally {
      signal.removeEventListener("abort", onAbort);
      await killing;
    }
  } finally {
    conn.release();
  }
}

postgres.js 4.0.0

export async function cancellableQuery(sql, text, signal) {
  // rejects a query waiting in the pool queue and cancels a running one.
  // A query already sent behind a running one is not rejected at the abort.
  return await sql.unsafe(text).signal(signal);
}

postgres.js 3.x (one reserved connection per request, the shape of the last scenario above)

export async function cancellableQuery(sql, text, signal) {
  const reserved = await sql.reserve();
  try {
    if (signal.aborted) return null; // the client left while we waited for a connection
    const query = reserved.unsafe(text);
    const onAbort = () => query.cancel();
    signal.addEventListener("abort", onAbort, { once: true });
    try {
      return await query;
    } finally {
      signal.removeEventListener("abort", onAbort);
    }
  } finally {
    await reserved.release();
  }
}

These recipes have one limit. Checking the signal after you get a connection stops an abandoned request from sending its SQL, but it does not cancel the wait for the connection itself. A request whose client leaves while it waits in pool.connect() or getConnection() stays queued until the pool hands it a connection. The check then releases that connection without running the query. That is what happened to the 8 queued requests in test 2. postgres.js 4.0.0's .signal() differs here. It rejected a query waiting in the pool queue, though not one already sent behind a running query (see above).

Query builders and ORMs have started exposing database-side cancellation too. Kysely 0.29.0 and MikroORM 7.1 both accept an AbortSignal and offer an inflightQueryAbortStrategy option with three values: 'ignore query' (the default), 'cancel query' and 'kill session'. Their APIs differ, but the distinction is the same. The Kysely API docs say the default stops waiting while the query keeps running on the server, and the connection goes back to the pool only after the query settles. That is the pool problem from test 2. 'cancel query' uses pg_cancel_backend on PostgreSQL or KILL QUERY on MySQL, and the Kysely 0.29.0 release notes show an optional controlClient for sending that cancel over a connection outside the pool, which is rule 3 below. MikroORM's query cancellation docs list the same three strategies. I tested none of these layers, so check them the way I checked the drivers, from the database side.

Here are the rules I would keep.

Check signal.aborted after you get the connection and before you send the query. A cancel that arrives before the statement starts does nothing. postgres.js 4.0.0 covers only part of this. In a one-connection check, .signal() rejected a query queued in the pool (max_pipeline: 1) after about 0.2 s. A query already sent behind a running one was not rejected at the abort. A slow one was rejected when the query ahead finished, and a fast one still ran to completion.
Read the pid or connection id on the connection that runs the query, in the same checkout, and only where one pool checkout keeps one database backend. That holds for a direct connection. It does not hold behind a transaction-mode pooler such as PgBouncer. In a quick check I ran earlier (PgBouncer 1.22.0, transaction mode, pool size 2, PostgreSQL 16, Node 22 and pg 8.23.1, all on localhost, with the details in a comment on my first post), reading the pid with a plain select pg_backend_pid() and then running the query as a separate statement was not safe. The pid changed between statements, and cancelling the stored pid cancelled another client's query with 57014. Inside an explicit transaction the pid stayed the same in my run. I did not test cancel pile-ups behind a pooler, and the tests in this post used direct connections.
Send cancels from a separate connection or a small dedicated pool. On pg 8.23.1, queueing several queries on one Client prints a deprecation warning that says the behavior will be removed in pg@9.0. My harness hit it by sending several cancels over one connection at once, so it now sends them one at a time.
Treat 57014 and ER_QUERY_INTERRUPTED as the expected result of a cancel, not as errors worth paging on, but do not read them as proof that your client cancelled. They only say a statement was cancelled. In PostgreSQL, statement_timeout and a DBA running pg_cancel_backend produce the same SQLSTATE 57014. In MySQL, a KILL QUERY that interrupts a lock wait produces the same ER_QUERY_INTERRUPTED error code. Check signal.aborted before you decide who cancelled.
Check the permissions of the account that sends the cancel. In PostgreSQL, pg_cancel_backend works on backends of your own role or of roles you are a member of. pg_signal_backend extends that, and only superusers can cancel superuser backends. In MySQL, KILL QUERY works on your own threads without extra privileges, and killing other accounts' threads needs CONNECTION_ADMIN or SUPER. My cancels run as the same user as the query. If yours run as a different account, test it.

A timeout is not the same as noticing that the client left. statement_timeout ends a statement after a fixed time whether or not anyone is still waiting for it, so you choose between cutting off slow queries that someone wants and leaving abandoned ones running. lock_timeout does the same for lock waits. Both are worth having as a backstop behind the cancel. Inside a transaction, SET LOCAL statement_timeout scopes the limit to that transaction, which is why it suits a transaction-mode pooler better than a session-level SET. None of these were part of this post's tests. I only tried a plain statement_timeout in my first post, and I did not test lock_timeout or SET LOCAL.

What I did not test

A full PgBouncer or RDS Proxy matrix. Cancelling by backend pid depends on holding the connection, and a pooler can break that. My only PgBouncer check is the quick one in rule 2, and it used pg.
Prisma, Drizzle, Kysely, MikroORM and other layers on top of these drivers. Kysely and MikroORM have their own AbortSignal support, described above, and I tested none of it.
Real CPU-bound queries. pg_sleep, SLEEP() and lock waits are easy to interrupt, and a long sort or aggregate may react differently.
Serverless drivers, remote databases and network latency. Everything here is localhost.
Other pool sizes, longer locks and other numbers of abandoned requests.
MariaDB Server. The mariadb connector was tested against MySQL 8.4.13.
Writes and other pool sizes in the .signal() ordering check, and postgres.js 4.0.0's cursor and transaction changes. Its release notes describe those changes, and I did not test them.
The recipes above are the patterns the tests ran, not a load-tested library.

node-postgres has pull requests that propose abortable queries, one with a signal option for queries (#3212) and a newer one for abortable query cancellation (#3751). #3212 was still open when I checked.

Run it yourself

You need Node.js 22 and Docker. The tests create a table named abortlab_lock, hold a row lock on it for 6 seconds and kill queries. Run them only against the throwaway databases that npm run up starts, which are bound to 127.0.0.1. Never point them at a database you care about. npm run down removes the containers and their data.

npm ci
npm run up
npm start
npm run starvation

npm start writes the test 1 table to results/matrix.md, and npm run starvation writes the test 2 table to results/starvation.md. The postgres.js reproduction is node src/repro-postgresjs-cancel.js. To run it against 4.0.0, pass the package name, as in node src/repro-postgresjs-cancel.js postgres4. The .signal() ordering check is node src/repro-postgresjs4-signal.js. Every Windows range in this post comes from node scripts/summarize-results.js, which recomputes them from the saved files in results/. The Linux numbers come from run #1 of the GitHub Actions workflow. Adding a driver is one file of about 50 lines, described in CONTRIBUTING.md.

If you run it against PgBouncer, RDS Proxy or a driver I left out, I would like to see your table.

Hono on Prisma Postgres and Compute, What Worked and What Broke

Shubhra Pokhariya — Thu, 29 Oct 2026 04:46:00 +0000

TL;DR

I deployed a Hono API on Prisma Postgres and Prisma Compute with three commands, auth login, build and deploy, and I never installed Bun.
One bug caught me. In this scaffold, if a route queries the database before the template's /users route does, /users returns a 500 and the log shows DRIVER.ALREADY_CONNECTED.
If you're sizing up the stack, Compute is GA, Composer (which declares and deploys Compute apps) is Early Access, and Prisma ORM 8 is still a release candidate at the time of writing. Pin your versions.

I wrote this article for Prisma, who commissioned it. The opinions are mine.

I built a small bookmarks API with Hono, put it on Prisma Postgres and deployed it to Prisma Compute. A coding agent, Gemini CLI, wrote most of the code from a prompt I wrote, and I kept a log of every error and every fix. The repo is public on GitHub, with the code, migrations, README and smoke test.

The app, a Hono bookmarks API with Prisma Postgres

I added six routes. GET /health, plus five for bookmarks (list, get one, create, update, delete). The scaffold adds GET / and GET /users, and /users matters later. A bookmark has an id, a unique URL, a title, optional notes and a createdAt.

I tested with Node 22.22.2, Gemini CLI 0.65.0 (with gemini-3.5-flash-lite selected), Prisma CLI 8.0.0-rc.21, @prisma/orm-postgres 8.0.0-rc.16 and @prisma/composer 0.28.0, in late October 2026. The Prisma packages have moved on since, so the findings apply to those versions. A re-run of the finished repo on Linux (Node and a local Postgres 16) is marked "on Linux" below.

A quick note on what you'd be building on. The Compute FAQ says Compute has been generally available since August 2026. Prisma's 28 August changelog and the Console both label Composer Early Access, and Prisma's docs call ORM 8 a release candidate at the time of writing.

I wrote the agent's rules in one prompt and made it stop after every phase. I ran every command that installed packages, used credentials or deployed to Prisma myself, and I never pasted my database URL into the agent.

Prisma Postgres with Hono, migrations and the direct vs pooled connection string

I created the database in the Console and it was ready in a few minutes. The connection dialog defaults to the pooled host (pooled.db.prisma.io) and tells you to put the string in .env. I came away with two things.

I used the direct host (db.prisma.io) for db:init, migrate and local dev. I didn't test the pooled string.
The scripts read DATABASE_URL from the shell, not from .env. On Linux, a valid .env file with no shell variable gave CONFIG.DB_CONNECTION_REQUIRED and created nothing. The Prisma Hono guide says the same.

The scaffold generates the first migration, and I generated the second with npm run migration:plan -- --name add-bookmarks. On my own database I ran db:init first (5 operations, the scaffold's tables) and migrate later, which applied the Bookmark migration. On Linux, migrate alone applied both migrations to an empty local database. The difference is that db:init builds tables straight from the contract, while migrate applies the migrations/ folder, which the Compute FAQ says a deploy applies for a Composer postgres() database. Both are safe to run twice (a second migrate says "Already up to date") and both mask credentials in their output. Every run also prints a pg warning that sslmode=require will change meaning in a future version.

Prisma ORM 8 unique constraint error and sqlState 23505

I put the rules in the prompt. Ids match ^[1-9][0-9]*$ and fit an int4, bodies over 10 KB get a 413 before parsing, URLs are stored as new URL(value).href, and the database's unique constraint decides duplicates. Gemini implemented them with a few early mistakes, including a wrong check order on PATCH, any types and a guessed duplicate check.

That guess is the interesting part. Gemini assumed a Postgres unique violation shows up as err.code === "23505". In ORM 8 the top-level code is undefined. I triggered a duplicate on purpose and logged the error. The useful fields, sqlState (23505) and constraint (Bookmark_url_key), sit on a SqlQueryError. The scaffold already ships the answer in .agents/skills/prisma-8/references/debug.md, which says driver errors "carry no dotted code" and to route on sqlState and the constraint metadata. My Phase 4 prompt named four skill files for Gemini to read and this wasn't one of them. I only read it while fact-checking this article.

Five simultaneous identical POSTs gave one 201 and four 409s.

Fixing DRIVER.ALREADY_CONNECTED in a Prisma ORM 8 Hono app

I had an 85-check smoke test ready before the API existed. The first run came back 84 passed, 2 failed. That adds up to 86 results from 85 checks because the script also records a failure for any 5xx response, so one broken route printed two FAIL lines. Both were GET /users, a route that ships with the scaffold.

{"error":"Could not query users yet. Run contract:emit and apply your schema first."}

The schema was fine, and the server log said something else.

Postgres client already connected
code: DRIVER.ALREADY_CONNECTED
fix: Call connect() at most once per client.

Here is what I worked out from the generated db.ts and the bundled dist/server.mjs. The ORM client connects in the background on its first query. The template's /users route goes through a helper that calls db.connect() explicitly. If one of my bookmark routes ran a query first, the background connect had already started and the explicit one threw. My routes queried db directly and never used the helper. This matches Prisma's runtime reference, which says to call connect() before any query or not at all, because a connect() after a query rejects with DRIVER.ALREADY_CONNECTED.

After a clean restart, GET /bookmarks followed by GET /users gave 500, and 500 again five seconds later. That also explains why smoke run 2 passed with no code change. I'd restarted the server, and the script requests /users before any bookmarks route, so the explicit connect ran first. On Linux the same unfixed code passed all 85 checks on a fresh process, and gave 84 passed, 2 failed once a bookmarks request came first.

Gemini's fixes were the weak part. The first matched the error message text and returned quietly, which hides the error. The second put await connectDatabase() at the top of every handler, before validation, so a bad body would need a database connection just to be rejected. I rejected both. The third calls the helper right before the first query in each handler, after validation, and leaves /health alone. After that /bookmarks, /users, /users returned 200, 200, 200 and a full smoke run gave 85 passed.

The Linux re-run also showed that the guide's own example triggers it. With the guide's POST /users route (step 4) added to a copy of the repo, a fresh process gave 201 for POST /users and then 500 twice for GET /users, with DRIVER.ALREADY_CONNECTED in the log. With GET /users first, the same three requests returned 200, 201 and 200. That was a local Postgres 16, not the deployed app, and the guide may have changed since.

The code compiled and my manual checks passed. Only a test run in the right order showed the problem. If you add a route to a Prisma scaffold, hit the template's own routes before and after yours, on a fresh process.

Deploy a Hono API to Prisma Compute

The Composer docs say local dev (prisma dev) isn't supported on Windows. I'm on Windows 10, so I never ran it, even though the scaffold's "next steps" box suggests it. These are the three commands I did run.

npx prisma auth login
npm run build
npx prisma deploy module.ts

All three worked. The Composer limitations page says deploys authenticate only with a service token, with "no browser flow", but the Composer deploying page documents auth login, and that's what I used. The two pages disagree and I couldn't tell which one is current.

I did three deploys.

The untouched scaffold took 3m 38s.
My bookmarks code took 3m 10s.
A redeploy of unchanged code took 50.4s.

Those are single runs from my machine, not a benchmark.

deploy doesn't build, so you run npm run build first. tsdown bundles everything into one dist/server.mjs of about 2 MB. The scaffold defaults to the us-east-1 region, and since I'm in India I changed one line in prisma.config.ts to ap-southeast-1.

The deployed app got its own Prisma Postgres database, and the migrated tables were there without my local DATABASE_URL being set. The deploy plan showed database-migrate (PrismaOrm.Migration) as updated, with no migration name. The Compute FAQ and the Compute limitations page both say the deploy applies your migrations/ to a Composer postgres() database before the service starts. My tables showed up after the deploy, which fits that, but I only know it from the result and not from the deploy output.

Compute runs the app on Bun even though my code is Node-style (@hono/node-server, built with tsdown for Node 22). The service log says starting bun with entrypoint: bootstrap.js. I installed nothing for that. The Composer getting-started page lists Bun as a prerequisite, so keep it in mind if local Node and deployed Bun ever behave differently.

The same 85 checks against the live app ended with 85 passed, 0 failed, 0 skipped. I didn't save the output. My paste and a screenshot show 79 of the 85 PASS lines, no FAIL line, and the final Result line with the totals. I created a bookmark, redeployed unchanged code and fetched it again, and got the same row. The app keeps no data in memory, so that fits the data living in Postgres. I can't say whether the redeploy restarted the app, so I haven't tested that.

prisma service logs app failed right after the deploy with PROJECT.SETUP_REQUIRED, saying the directory wasn't linked to a project. It needs --project bookmarks-api. The log held two lines and no request lines. The Console overview also said "no deploys yet" while the app was live. The CLI had told me it wasn't recording the deploy because the folder had no git commit, so that may be expected, but I didn't check.

Prisma Compute latency from India

These numbers are my own network path to ap-southeast-1, not a benchmark, and the bookmarks table was empty. The idle test sent one request to /health and then one to /bookmarks from the same process, so the second request likely reused the first one's connection and skipped DNS and TLS. I didn't verify that. The 30 warm requests per endpoint came about 70 seconds later.

Test	`/health`	`/bookmarks`
First two requests after about 16 hours idle (estimated)	682.7 ms	363.5 ms
30 warm requests, median	120.8 ms	127.5 ms
30 warm requests, p95	745.7 ms	134.9 ms

Twenty-eight of the 30 warm /health requests took 116.5 to 130.8 ms. Request 1 took 745.7 ms, and with 30 values that is also the p95, so it says little about typical latency. Request 20 took 967.9 ms and I don't know why. Prisma says idle Compute instances resume in milliseconds, but I can't call my idle figure a cold start because DNS, TLS and any wake-up are mixed into it.

npm audit on a Prisma Compute project and its 14 vulnerabilities

npm ci reports 14 vulnerabilities (5 moderate, 9 high). On Linux they traced back to alchemy and an old nested @prisma/dev, plus lodash through a parser package. Also on Linux, a search of dist/server.mjs found no @prisma/dev or lodash, and its only alchemy mentions are three code comments. The app itself uses the top-level hono 4.13.13 and @hono/node-server 2.1.5, which the audit doesn't flag. A bundle search is not a security review. Don't run npm audit fix --force, because it proposes @prisma/composer and @prisma/composer-prisma-cloud 0.6.0 and prisma 7.10.1, a step back from ORM 8.

What worked, and what I'd tell the Prisma team

What worked well. Once I'd signed in with auth login, build and deploy ran without prompts, and the deployed app arrived with its own database. The doc comments in the installed types also say what update and delete return when nothing matches.

What I'd suggest to Prisma. Each of these comes from something I saw.

The template's /users error tells you to run contract:emit, but the server log showed DRIVER.ALREADY_CONNECTED. Logging or returning the underlying error would save someone an afternoon. The runtime reference and the scaffold's skill file describe the lazy connect, but the Hono guide I read doesn't, and the template's own helper calls connect() explicitly. The guide's own POST /users example queries db without connecting, so it runs into the same error.
The Composer limitations page says deploys use a service token with no browser flow, while the Composer deploying page documents auth login. A note on which is current would settle it.
The deploy plan could name the migration it ran.
prisma deploy found my project from the folder, but prisma service logs said the directory wasn't linked to one. Sharing that link between the two commands would save a step.
The ORM 8 query types live in @prisma/orm-family-sql, not in the package you install, so they took several searches to find.
Versions move fast. A couple of days after I scaffolded, the CLI was telling me 8.0.0-rc.27 existed.

Before you copy the repo

GET /users is a scaffold route, and it inserts three sample users on its first call.
createdAt comes back as Postgres text (2026-10-23 16:33:47.512805+00), not ISO 8601, because the contract uses the scaffold's TimestamptzString type.
There's no auth, so anyone with the URL can write to it. Prisma's pricing page gives the Prisma Postgres Free plan 200,000 operations a month, and the Compute FAQ says the Free plan has no backups. I'm not publishing my live URL.
A NUL character (\u0000) in title or notes returns 500 instead of 400. A lone surrogate or invalid UTF-8 is stored as the replacement character. These turned up when the repo was probed with odd input on Linux, and the 85 checks don't cover them. They're listed in the README and not fixed.

What I didn't test

I didn't test prisma dev (unsupported on Windows), the pooled connection string, the Prisma MCP server, Bash on Windows or macOS, or how Compute behaves when idle database connections drop. I tested one small API with an empty table, so I can't speak to load or larger projects. The docs changed several times while I worked, so re-check the linked pages before you rely on any of this.

My verdict

I'd use this stack again. Going from a scaffold to a live API with its own Prisma Postgres database took three commands. The one real bug I hit depended on the order my routes and the scaffold's /users route queried the database, and I could trace and fix it. At the time of writing, ORM 8 is still a release candidate and Composer is in Early Access, so before I ran production traffic on it I'd wait for those, and for the docs to agree on auth. The code, README and smoke test are in the repo.

The Garden I Wait for Every Winter

Shubhra Pokhariya — Sun, 18 Oct 2026 12:21:49 +0000

October always makes me look at my garden a little differently.

The monsoon is beginning to fade, the mornings are changing, and I'm already thinking about winter. Not just the cooler weather, but the winter garden I want to create over the next few months.

I've started preparing some of the pots and thinking about what I want to grow. Petunias are always somewhere in my plans. I use them a lot, and I never seem to get tired of finding another place where they might work. Alyssum usually finds its way into my ideas too.

Then there are all the little decisions. Which plants would look good together? Where should the brighter flowers go, and where would a quieter combination of greenery and softer colours work better? Sometimes I've imagined an entire arrangement before I've even bought the plants. Nothing has really changed yet, but in my head, the garden is already beginning to look different.

A winter garden full of colours and little corners

I don't want every part of my garden to look the same.

Some corners can be full of petunias, with flowers spilling over the sides of their pots. Alyssum can soften another arrangement and fill the smaller spaces around other plants.

Then there are the quieter corners. I like having ferns, snake plants, and coleus around too. They aren't there to replace the winter flowers. They give the garden something to look at between the blooms, with different leaf shapes, textures, and shades of green. Coleus is especially fun when I want foliage to bring some colour of its own.

And then there is the edible side of the garden. I enjoy growing things that eventually make their way into the kitchen. Spinach and other leafy greens, radishes, carrots, lettuce, herbs, and strawberries all have their own place. They make the garden feel less like something I only look at and more like something I take part in.

I don't need every corner to do the same job. One can be bright and full of flowers, another mostly foliage, while somewhere else I might have vegetables growing in a pot that I check every morning. That mix is what makes the garden feel like mine.

Arranging plants in pots

I especially enjoy putting different plants together in one container. I don't always want a single plant sitting alone in a pot. I like combining different shapes, heights, colours, and growing habits so the arrangement changes as you look at it.

For this I like the thriller, filler, and spiller approach. Something taller gives the pot some height, fuller plants fill the space around it, and trailing plants spill over the edge. Petunias are wonderful for that last part once they start growing over the sides. Alyssum can fill smaller gaps and soften the edges, while a taller plant gives the whole pot some structure. I enjoy picturing all of that before I start planting.

Of course, plants rarely follow the picture in my head. One grows faster than another. Something needs more room than I expected. A plant that looked perfectly placed when I first arranged the pot can look crowded a few weeks later.

So I move things around.

Sometimes changing the position of one plant makes the whole pot look different. Sometimes I swap one companion for another. And sometimes the combination I didn't expect to work becomes the one I like most. That's what I enjoy about arranging pots. There's always another combination I want to try.

Between coding and gardening

Most of my working day is spent coding, and when I'm working, I like being completely focused on it. I enjoy getting deep into a problem, understanding how the pieces fit together, and staying with it until I find a solution. Gardening gives me something completely different to focus on.

When I step away from my laptop, I might go outside, look at the pots, and notice something that needs attention. An empty pot might give me an idea. A plant that has grown more than I expected might make me rethink the corner around it. Sometimes I don't even do anything. I just walk around and look.

There is a small similarity to designing something before building it in code. I think about the different pieces, imagine how they might fit together, try a few possibilities, and sometimes change the whole plan before I start.

But the garden has one rule that software doesn't: I can't make it happen faster just because I'm ready. I can prepare the soil, choose the plants, arrange the pots, and give everything the space it needs. After that, the plants take over. A petunia doesn't bloom because I'm impatient to see the final arrangement. A spinach plant doesn't grow faster because I keep checking whether it is ready to harvest.

They take their time. And I like that.

Getting ready for the season

For me, winter gardening isn't only about the garden when it is finally full of flowers. I enjoy everything that comes before that too.

There are pots to clean, soil to refresh, plants to choose, and arrangements to rethink. I get to decide what I want to try this year without knowing exactly how it will all turn out. Some combinations will work the way I imagined. Some won't.

A plant might grow in an unexpected direction. Something I thought would be a small part of an arrangement might become the thing I notice most. A simple combination might turn out better than the complicated one I spent much longer planning. Sometimes a plant just doesn't cooperate with my plan, and that's fine. I can move it, give it more space, pair it with something else, or try a different spot. The garden doesn't mind if I change my mind.

A little space to create something of my own

I've already started shaping a few corners into what I imagined. Some days I spend more time with the flowering plants. Other days I find myself looking at the spinach, the herbs, or the strawberries and noticing how much they've changed. That's one thing I love about growing so many different kinds of plants. There is almost always something happening somewhere.

Eventually, I'll come back inside, clean up, open my laptop, and return to my work. I may not come back with a brilliant new idea. Maybe I'll simply feel happy about the little corner I've started creating.

And I think that's enough.

Not everything has to become a lesson. Sometimes it's enough to step away from a screen, spend time doing something I love, and watch it grow at its own pace.

What about you? Is there something outside your work that you look forward to, even before it begins?

Your Auth Check Passed. The Agent Still Did Something Nobody Asked For

Shubhra Pokhariya — Tue, 13 Oct 2026 07:30:23 +0000

Authentication answers who. Authorization answers what they're allowed to do. Neither one answers whether this specific action was actually intended.

That's the gap I wanted to test. I built a small AI agent and tested it against several failure cases before I got to a result I was confident in. I'm including that part too, because pretending everything worked on the first try would be its own kind of false claim.

Disclosure: Arcjet commissioned this article. I chose the angle, wrote the code, and ran the tests independently. Arcjet reviewed the technical outline for factual accuracy, not the conclusions.

The authorization gap in AI agents

Earlier in this series I made the case that a Server Action isn't a function call, it's a public POST endpoint wearing a convenient syntax. That post was about who can reach the action and whether they're allowed to. This one is about a question a model changes entirely. Once a model is deciding whether to call that action, being "allowed to" stops being the whole story.

A human clicking a button is one kind of signal. A model generating a tool call from the contents of a document is a different kind of signal, and none of the checks from that earlier post, not the ownership check, not the role check, not the proxy in front of it, were built to tell the two apart. That's not a flaw in that post's argument. It's a different question the three-layer model was never asked to answer.

The setup

I built a small Next.js research assistant. It reads a document, summarizes it, and if the document mentions filing an expense, it calls a fileExpenseReport tool to do it. Nothing fancier than that on purpose. I wanted the security behavior easy to reason about, not buried under unrelated complexity.

The stack: Vercel AI SDK, Gemini as the model, Arcjet's Guard SDK wired in at two separate points:

import { launchArcjet, detectPromptInjection } from "@arcjet/guard";
import { guardTool } from "@arcjet/guard/vercel-ai/v7";

detectPromptInjection screens the inbound document before the model ever sees it. guardTool wraps the actual tool call. They're two separate enforcement points answering two different questions, not one check doing double duty. Collapsing them into a single check is the mistake this whole piece is about, so I kept them apart on purpose.

Everything below is real output from my own account. Synthetic accounts, synthetic data, real Arcjet decisions. The "database" is a stub that logs each insert to the console, so a "database write" here means a call to that stub.

The legitimate baseline

First run: a normal document, a normal expense, nothing adversarial. The model read it, called the tool, and the database write went through. That's the control case, the thing that has to keep working while everything else gets locked down.

Attack one: the obvious injection

Next, I planted a document with a direct embedded instruction, something that told the agent to file an expense to an account nobody had actually asked about. detectPromptInjection caught it and denied the request before the model ever got a turn. The Arcjet dashboard showed the same event independently, marked PROMPT_INJECTION, sitting among otherwise clean entries.

One thing from an earlier, less finished run of the same fixture: the injection got past detection once, and the model declined to act on its own. I'm not counting that as a security control. A model refusing to do something today doesn't mean it refuses tomorrow, and treating good judgment from an LLM as your actual security boundary is exactly the mistake I built this whole test to avoid making.

A planted document is the version I actually built and tested, but it's one instance of a broader category. The same gap opens whenever the content driving a decision comes from somewhere the user didn't type it themselves, an email thread the agent summarizes, a page it scrapes, the output of a previous tool call feeding into the next one. I only have real results for the document case. I'm not going to claim I tested the others.

Attack two: the one that actually mattered

The obvious injection is the easy case. The interesting one is the paraphrased version, no "ignore previous instructions," no imperative override, just the same underlying request phrased like an ordinary business note.

detectPromptInjection let it through. The model attempted the tool call. And the action boundary, a plain allow-list check inside the tool's own execute() handler, rejected the account and left no database write behind.

That contrast is the center of the piece. Detection and authorization answer different questions. A detector asks: does this content look suspicious? The tool boundary has to ask something else entirely: should this specific call, with these specific arguments, actually run right now? A clean detection result doesn't answer that second question, and building your security around the assumption that it does is how paraphrased attacks get through.

Authorize the AI tool call before the side effect

The check that stopped this particular attack is deliberately boring: a plain application-level allow-list inside the tool's own execute() function. Worth being precise here since it's easy to conflate the two: guardTool is the Arcjet wrapper around the tool call, and the allow-list below is my own application logic. It only runs once a call has already gotten past guardTool, sitting immediately before the database write as its own separate, deterministic check.

if (!ALLOWED_ACCOUNTS.includes(input.accountId)) {
  return {
    denied: true,
    boundary: "action",
    reason: "account_not_allowed",
    message: `Account ${input.accountId} is not on the allow-list`,
  };
}

I return a structured result instead of throwing. The function exits before the database write, and the result gives the model a clear explanation for the denial. If the model retries, the same allow-list check runs again.

No exotic API, no clever abstraction. That's the point. The check doesn't need to be sophisticated. It needs to sit in the right place: after detection, after the model's decision, immediately before the side effect.

A tool call is a proposal from the model. A successful side effect is a decision made by the application. Those are not the same event, and treating them as the same event is exactly how a clean-looking request turns into an unauthorized database write.

Re-running the full matrix

I confirmed the pattern held across the rest of the set: a benign document with imperative-sounding language that shouldn't trigger a false positive, and it didn't, no tool call attempted at all. A clean document with an ambiguous instruction, no injection pattern present anywhere, still denied at the action boundary. That last one matters on its own, it proves detection alone wouldn't have caught it, because there was nothing for a detector to catch.

Why the usual layers don't close this gap

None of this replaces a proxy, a WAF, or RBAC. It's not a substitute for any of them. But it's worth being precise about what each one actually answers. A proxy or WAF sees a clean, authenticated POST request. RBAC correctly returns yes, this user is allowed to file expenses. Neither has any visibility into whether this particular call, with these particular arguments, was something the user actually intended. They're solving a different problem, and they solve it well. They just don't solve this one.

The remote-policy detour

I also tested Arcjet's remote policies, which Arcjet documents as a way to change enforcement logic centrally without redeploying the application.

The first runtime attempt didn't work cleanly. A config mismatch on my end needed fixing before the policy behaved as intended.

With that corrected, and the local allow-list temporarily expanded so it couldn't be the thing making the decision, the same running application produced two results:

Allowed account, policy in Live mode: the model called the tool with the account the policy explicitly permits, Arcjet returned ALLOW, and the database write happened.

Denied account, same code, same deployment: the model called the tool with a different account, and the response came back DENY, reason INPUT_CONSTRAINT, no error, no fallback behavior, a genuine policy match. Nothing wrote to the database.

That's what I wanted to verify with the remote policy: the decision about which accounts are allowed lived in Arcjet, not in my application code. The same running server, with no code changes, allowed one account and denied the other based on a policy I manage centrally. Per Arcjet's docs, editing that policy changes enforcement without a redeploy, though the SDK caches policies and rechecks them every few minutes, so changes are not instantaneous. I didn't test a policy edit between runs.

Tool call is not the same thing as executed

This is worth stating on its own, because it's the core claim the whole article rests on. When you check whether a tool call happened, you're checking whether the model attempted something. That's not the same as checking whether the underlying action executed. A denied call can still show up as a tool call in your logs. In my test, it never reached the database write. The same distinction matters for whatever consequential operation your tool actually performs, whether that's a database write, an external API call, an email, or a payment. If your logging conflates those two things, you can end up believing a security check is working when it's actually just recording attempts, not outcomes.

If a denied call still shows up in your logs, it's worth deciding upfront what you actually want recorded at that point:

{
  toolCall: "fileExpenseReport",
  decision: "DENY",
  boundary: "action",
  reason: "account_not_allowed",
}

Structuring it this way means an attempted-and-blocked call is unambiguous in your own telemetry, not something you have to reconstruct later by cross-referencing tool-call logs against database writes.

PII is a different boundary

Prompt-injection detection and authorization don't solve the same problem as sensitive data leaking to a model or a downstream tool call. If a document contains an email address, a phone number, or a government ID, checking the model's response is already too late, the data has already crossed the provider boundary.

I didn't run a real test of this as part of this project's matrix, so I'm not presenting one as an experiment result. But it's worth naming precisely rather than skipping past it, because the boundary is different from everywhere else in this piece. It's not right before a side effect, it's wherever sensitive data is about to leave the application's control at all, a document going to the model provider, a tool output feeding back into model context, a value about to appear in a log.

Arcjet's Guard SDK also provides local sensitive-info detection for agent and tool paths, so detection can happen in-process before sensitive content crosses another boundary. Detection tells you something sensitive is present. Redaction lets the model continue without the original value. Blocking is the right call when the value should never leave the application at all.

Automated traffic is a separate concern

One more boundary worth mentioning, because it answers a genuinely different question than everything above. I sent a real curl request to a small API route using the same Arcjet HTTP-boundary client, then sent the same request with its User-Agent changed to look like a normal browser. Both were denied as bots. Changing only the User-Agent didn't change the result. I can't say precisely which signals contributed to that decision, so I'm not going to guess at the mechanism.

I'm keeping this separate because it's a different question. An authenticated, authorized, perfectly legitimate-looking request can still be automated and abusive at volume. Request-level bot detection and rate limiting belong at the HTTP boundary, alongside the application-level checks, not instead of them.

Where this pattern doesn't help

A legitimately authorized user asking for something genuinely bad isn't caught by any of this. That's not a prompt-injection problem, it's a business-authorization problem, and it's still squarely your application's responsibility to define who's allowed to do what.

And the model's own judgment is not something to lean on as a security control, however good it looks in a given run. I saw a model decline to act on a bad instruction in one run and comply with an equivalent instruction it hadn't seen worded that way in another. That's exactly why the check needs to live in code that runs the same way every time, not in whatever the model happens to decide.

Runtime enforcement isn't free either. Each additional check adds processing and operational complexity, and remote policy evaluation introduces another dependency that needs explicit failure handling. The right tradeoff depends on how consequential the operation is and how much latency the application can tolerate.

What the experiments actually proved

Test	Result
Legitimate request	Tool called, database write succeeded
Obvious injection	Denied by detection, corroborated in the dashboard
Paraphrased injection	Passed detection, denied at the action boundary
Benign content, imperative language	No tool call attempted
Clean content, ambiguous instruction	Denied at the action boundary, with no injection pattern present
Remote policy, allowed account	Evaluated, allowed, wrote to the database
Remote policy, denied account	Evaluated and denied by the remote policy, with no database write
Real automated request	Denied as a bot; changing the User-Agent did not change the result

A practical pattern

If you're building anything where a model can trigger a consequential action, put an explicit, application-level check immediately before that action for anything in this category:

money movement
deleting data
changing permissions
sending external communications
refunds
production changes

Authentication and authorization should still happen upstream, same as always. This check isn't a replacement for either. It's a specific, narrow boundary sitting right in front of the operation that actually causes harm if it's wrong.

Before an AI agent can cause a side effect

Is the user authenticated?
Is the user authorized for this resource?
Is content influencing the model treated as untrusted?
Is the tool call independently authorized?
Are the actual tool arguments checked, not just the fact that a call happened?
Does denial happen before the side effect?
Can sensitive data leave the application?
Can automated traffic reach the endpoint repeatedly?
Have you verified that a denied call produces no side effect, not just a log entry?

The model doesn't own the security boundary

Authentication tells you who's asking. Authorization tells you what they're generally allowed to do. Neither one tells you that this specific action, generated by a model, from content it read somewhere, was actually something anyone intended. That check belongs at the action itself, checked in code that behaves the same way on every run, not inferred from whether the request looked clean upstream or whether the model seemed to behave reasonably this time.

Put the boundary where the side effect happens. Everything else is a proposal until then.

I Built an AI Gardening App That Tells Me to Put the Laptop Down

Shubhra Pokhariya — Sun, 11 Oct 2026 12:54:29 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Coding is my thing. Gardening is a part of who I am.

I have hundreds of pots, and I know my plants through the little things they show me. I notice which ones respond well to buried banana peels, which seem happier with used tea granules or old buttermilk, and which need my lunch-box system instead of raw kitchen scraps buried around them. I watch their leaves, new growth and flowers.

I do not need an app to tell me how to care for my own plants. That understanding comes from spending time with them. But it made me think about how a tool could help someone who is still learning to notice these things.

For a long time coding and gardening lived in different corners of my day. I would code for hours, then walk away from the screen to be with my plants, and the two never really met. This challenge gave me a reason to put them in the same room. So first, thank you to the DEV team and everyone behind it. You gave me the opportunity to write code about the thing I love most, and I enjoyed every hour of it.

The question I almost asked an AI

On 30 September I moved my marigold out of a shady, bright corner and into the open sun. The corner was there to keep the heavy rain off it. It grew from a cutting of a plant that came up by itself from last year's seeds, so it already feels a little like family.

On 5 October I counted about three open flowers and three buds. On 9 October I counted seven open flowers and five buds.

My first thought was to ask an AI why.

An answer would have been easy to get and easy to believe. But the sun, rain and time passing had all played a part, and I couldn't tell which one made the difference. Neither could an AI. So I asked a different question. Not "why is my plant doing this?" but "what should I look at before I change anything?"

That question became Garden Trials.

What I Built

Garden Trials is a small app that runs entirely on your own computer. The whole idea fits in one line, which is look first, change one thing, let the garden answer.

I do not like screens near my plants. When I am with them I want my hands in the soil and my phone away. Sometimes a bloom looks so good that I click a photo, for myself and for other plant lovers. So I built the app the way I wish gardening tools worked. It talks to me before and after, and in the middle it asks me to put the laptop down and go and look.

I write a note about a plant and the day I saw it. A local Gemma model reads it into plain facts.
The app asks me to check one specific thing on the plant. Until I write down what I found, it will not suggest anything.
I either watch, or pick one change from a small fixed menu, ideally leaving a similar plant alone to compare.
I count and take a photo. The app shows me the last photo so I can match the angle.
I get a table, a chart, a verdict, an evidence level from 0 to 3, and one plain next step.

It is not a plant doctor. It never says what is wrong with a plant, and it never says what caused a result.

Garden Trials is for gardeners who are still learning to read their plants, and for anyone who wants to check their assumptions rather than jump to conclusions. It brings observations, follow-up checks, simple experiments and evidence tracking into one process. Instead of just recording what happened, it helps gardeners look at what changed, what else might have affected the result, and what their observations can actually tell them. It is not meant to replace the understanding that grows from spending time with plants, but to encourage closer observation.

Demo

The quickest way in is the sample garden. Tick "Try the illustrative sample garden" in the sidebar and you can walk through the whole loop with made-up plants. Nothing from it is ever saved to a real garden.

Code

shubhrapokhariya / garden-trials

Local Gemma 3 1B app (Ollama + Streamlit) that sends gardeners back to their plants to look first, helps them test one change at a time, and assigns each result an evidence level from 0 to 3.

🌱 Garden Trials

Look first. Change one thing. Let the garden answer.

A small local app for gardeners. A Gemma model running on your own laptop helps you write down what you see and asks one thing to go and check on the plant. Plain Python builds the experiment, keeps the records and works out how much the evidence really shows. The app never says what caused a result.

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

Demo video (48 seconds, no sound): https://youtu.be/Rm7X4btlZVk

Quickstart

Install Python 3.11 or newer and Ollama. The tests were run on Python 3.11.
Download the code, then in its folder run:

python -m pip install -r requirements.txt
ollama pull gemma3:1b
python -m streamlit run app.py

On Windows you can double-click run.bat instead. On macOS or Linux, run bash run.sh. Both scripts still start the app if Ollama is missing…

View on GitHub

Setup is in the README: Python 3.11 or newer, Ollama, ollama pull gemma3:1b, then python -m streamlit run app.py. The folder examples/my-garden/ holds my real notes, counts and photos from this week. Start the app with GARDEN_DIR=examples/my-garden and you can read them without touching your own data.

My real garden, this week

Petunia

On 7 October I counted two open flowers, one spent flower, four buds and a lot of tiny buds forming. I took photos and counts on 7, 8, 9 and 10 October, but I only opened the app on the 10th, so I typed the first three days in afterwards. The app marks those entries as backfilled, which is exactly what they are. It is also why the trial says it started on 10 October.

When I saved the 7 October note, Gemma's reading dropped a number, so the app threw the reading away and kept my words exactly as I wrote them. Then Gemma's Look First question turned out to be about pests or disease, which I had never mentioned. The app blocked it and asked its own question instead:

Count the open flowers and the buds right now. Do the newest shoots have buds?

I went and looked on the 10th. Four open flowers, two bright ones on top and two darker ones lower down that had just opened, and small buds at the tips of the shoots.

Date	Open flowers	Buds	Note
7 Oct	2	4	Front view. One spent flower not counted.
8 Oct	2	4	Removed the spent flower. Photo from above.
9 Oct	2	4	Buds clearly bigger and longer.
10 Oct	4	2	Two buds opened. Bright sun, so the reds look brighter.

I removed one spent flower on the 8th. That was routine upkeep, not a test, but I want to say so. There was no comparison plant, and petunia buds open on their own anyway. The app gave this evidence level 0 and said it plainly. No change was made during these counts, so it shows what the plant did while I watched and says nothing about a cause.

The two new flowers opened darker and more velvety than the older ones. I read that a new petal is still small and tightly folded, so its colour is packed close together, and that as the flower opens fully and stretches out, the same colour spreads over a bigger petal and looks lighter. So I guess that is what I am seeing.

Marigold

The 5 October photo was taken for myself, not for the trial. I clicked it just because the plant looked lovely, from the side, and only later decided to use it here. One bud is partly cut off at the edge. The 9 October photo is the one I took for the trial, from above, where every flower and bud can be seen. My first count may have missed buds I could not see from the side, so the jump from 3 to 7 open flowers is in my notes, but it is not a fair comparison. A few petals also looked flattened after some rain. The rain may be the reason, but that is a guess.

Bougainvillea

Five cuttings, about a month and a half old, in the same soil and the same small black nursery bags on the same bench. One of them already has two pink flowers and the other four have none. Its mother plant is in full bloom, while my other bougainvilleas are only starting. My guess, not tested, is the variety or the time of year. The cuttings are different varieties, so "same soil, same bench" is not a fair test. A real test needs cuttings of the same variety, taken at the same time from different mother plants.

How I Built It

The stack is small on purpose: Streamlit, one JSON file, and gemma3:1b running locally through Ollama. I picked the 1B Gemma model to find out whether this idea works on an ordinary laptop with no cloud account. On a laptop CPU an answer can take up to a minute.

Gemma has three jobs. It reads my note into plain facts, suggests one thing to go and check, and picks one change from a short menu. Everything that has to be reliable lives in plain Python, because I treat the model's output the way I would treat any untrusted input.

If a number from my note is missing in Gemma's reading, the reading is rejected and my exact words are kept.
Details Gemma adds that I did not write are removed by a word-match check. It is a loose check, so it can miss some.
The cause field is forced to "unknown" in code.
Pest and disease questions are blocked unless I raised them first.
Trials come from a fixed menu that is filtered per plant. "Water more" is never offered for bougainvillea, which likes to stay on the dry side.
Verdicts and evidence levels are calculated by code, never by Gemma. Level 3 needs two finished trials of the same change, each with a comparison plant and nothing else changed, all pointing the same way.
Saves go to a temporary file first and are then swapped in. A garden file that cannot be read is moved aside and never overwritten.

The tests replace Gemma with fake and deliberately bad answers, such as garbage, dropped numbers, invented pests, off-menu picks. A second set drives the real pages end to end. There are 85 tests, and none of them needs Ollama.

What went wrong

The model did not behave in my own garden. Gemma's reading of all three of my notes was rejected by the number check, and one of its three questions was blocked.

The other two questions got through, and they were generic. "Is the plant's stem straight?" had nothing to do with what I was seeing, so I wrote down what I actually noticed. The guards block invented pests. They cannot make a small model's question a good one. They also only catch the failures I thought of, and the checks match English words, so notes in Hindi are not checked the same way. In my real garden Gemma only read my notes and wrote Look First questions. Both of my real trials were watch-only, so it never picked a trial there.

Why Does Open Innovation Matter?

Gemma runs on my laptop through Ollama. There is no API key, no usage bill and no cloud AI call. My notes and photos sit in a folder on my own machine, and the photos are saved without their location data. Setup needs the internet once, to download the packages, Ollama and the model, and I switched off Streamlit's anonymous usage statistics.

Running Gemma locally let me build and test this idea without an API key and without paying for every request. I could try it as often as I liked, and if a better small model arrives, I change one setting (OLLAMA_MODEL) and the rest of the app stays as it is. The small model had clear limitations, which I describe above, but that was part of what I wanted to learn, which is how far an open model can take this idea on an ordinary laptop, with ordinary code checking its output. The experiment showed me both the value of running a model locally and the limits of relying on its answers.

What I took away

The point of the app is what happens when I close the laptop. It asks me to go and look, and I stand there with the plant and nothing else. It cannot tell whether I really went outside, and I will not pretend it can. That pause is a promise I make to myself.

The AI can suggest what to look at. The garden gives the answer.

Thank you for reading, and thank you again to the DEV team for a challenge that let me bring the two things I love together.

Prize Categories

Best Use of Gemma

Aborting a Fetch Doesn't Stop Your Node.js Server. Here's What Does.

Shubhra Pokhariya — Tue, 06 Oct 2026 08:47:00 +0000

I fired 20 requests at a Node.js handler and made every client walk away after 100 ms. The handler was five steps of 200 ms each, so 100 steps of work in total if nothing got cancelled.

Nothing got cancelled. The server finished 100 of 100 steps for clients that were already gone.

Then I taught the handler to notice the disconnect. Same 20 abandoned requests, and this time it ran 0 of 100 steps.

If your frontend calls controller.abort() when a user switches a filter, your backend may be doing the same thing right now. The client-side abort is real, but it doesn't automatically reach the work your server is doing. I wanted to know exactly where it ends, so I tested node:http, Express 4 and 5, Hono and a real PostgreSQL database. Node 22.22.2 and 24.21.0, pg 8.23.1, PostgreSQL 18.4, HTTP/1.1, everything on localhost. I used Node's built-in fetch as the client, not a browser.

Three results surprised me:

node-postgres accepted a { signal } option and silently ignored it.
req.signal exists on Node 24 and is undefined on Node 22, with no warning.
Sending the Postgres cancel through your normal pool can hang it.

Where the cancellation stops

client        abort() -> fetch rejects, connection closes
server        sees a closed socket
your handler  keeps running
fetch to      keeps running
another API
SQL query     keeps running

Only the first two lines happen on their own. Everything below them is code you have to write. A synchronous CPU loop is a special case, and I'll get to it near the end.

What the server sees when a client aborts

I wrote a handler with five 500 ms steps and aborted from the client at 1200 ms:

[1216ms] client: abort()
[1223ms] client: caught AbortError
[1225ms] server: res 'close' (writableEnded=false, destroyed=true)
[1548ms] server: step 3/5 done (socket.destroyed=true)
[2562ms] server: step 5/5 done (socket.destroyed=true)
[2567ms] server: res.end() called, no error thrown

The client was done in 7 ms. The server noticed something, because the response emitted close. But the handler is just an async function, and nobody told it to stop. Steps 3 to 5 ran against a dead socket, and res.end() didn't even throw.

How to detect a client disconnect in Node.js

Listen for close on the response. The Node http docs say ServerResponse emits it when the response finishes or when the connection drops before that. Inside the handler, check res.writableFinished to tell the two cases apart. It was true after a normal response and false after an abort.

I skip the request's close event. It also fired on disconnect in my runs, but the docs only promise it means the request was completed, and I don't want to build on something that isn't guaranteed.

This is the helper I ended up with. It merges "the client left" with a server-side deadline:

export function requestSignal(res, { timeoutMs } = {}) {
  const gone = new AbortController();
  res.once("close", () => {
    if (!res.writableFinished) gone.abort(new Error("client closed request"));
  });
  const signals = [gone.signal];
  if (timeoutMs) signals.push(AbortSignal.timeout(timeoutMs));
  return AbortSignal.any(signals);
}

Pass the result to anything that takes a signal:

const signal = requestSignal(res, { timeoutMs: 600 });
const r = await fetch(upstreamUrl, { signal });

When the client left at 200 ms, my API stopped and the downstream request closed early. With the 600 ms deadline, the client got a 504 and the downstream request closed early too. signal.reason tells you which case you're in: a TimeoutError for the deadline, or your own error for a disconnect. In an earlier run with a hand-wired controller, the cancel travelled from the client through the API to the downstream service in about 25 ms.

Two details that cost me time:

Create the timeout signal inside the request. AbortSignal.timeout() starts counting when you call it, so a module-level one expires once and then fails every request.
AbortSignal.timeout() rejects with TimeoutError, not AbortError. If your catch only checks for AbortError, timeouts slip through. Check e.name.

AbortSignal.any needs Node 20.3 or 18.17, and AbortSignal.timeout needs 17.3.

Does Express have req.signal? It depends on your Node version

Recent Node versions give IncomingMessage a built-in signal. Here is what I saw:

Node 22.22.2, node:http, Express 4.22.3 and 5.2.1: req.signal is undefined.
Node 24.21.0, same setups: it exists, and the handler stopped when the client left.
Hono 4.13.12 with @hono/node-server 2.1.3: c.req.raw.signal fired on both Node versions.

The Node docs list req.signal as added in 24.16.0 and 26.1.0. There is a catch for the versions right after that. On 24.16 to 24.19 and 26.1 to 26.6, the signal can abort after a perfectly normal request finishes, which makes it unreliable for spotting a real disconnect. The fix landed in 24.20.0 and 26.7.0. If you run something in between, upgrade or test it yourself.

The Node 22 case is the sneaky one. sleep(ms, null, { signal: req.signal }) passes undefined, runs without any cancellation and throws nothing. The res 'close' helper above behaves the same on every version I tried, which is why I kept using it.

Does aborting a fetch stop a running Postgres query?

No. I ran select pg_sleep(3) in a handler, aborted the client at 500 ms, and asked Postgres from a second connection what was still running:

[ 917ms] api: client left
[1227ms] DB: active pg_sleep queries 300ms after client left = 1
[3494ms] api: query finished normally

Postgres kept working for about 2.6 seconds after the client left. With a real report query, that means a held connection, wasted CPU and sometimes held locks.

node-postgres ignores the signal option

The API shape makes this tempting:

await client.query({ text: "select pg_sleep(2)", signal });

With pg 8.23.1, the query ran for 2009 ms and nothing was thrown. I also searched the installed pg, pg-pool and pg-protocol code and found no AbortSignal handling. Proposals exist in the node-postgres repo, but none of that was in the version I tested. So this is about pg 8.23.1 only. It fails silently, so you only catch it by testing.

How to cancel a Postgres query with pg_cancel_backend

What worked was asking Postgres to cancel the running statement from a different connection, because the busy one is stuck inside the query:

// the cancellation part only, not a complete handler
const signal = requestSignal(res, { timeoutMs: 5000 });
const client = await pool.connect();
const { rows: [{ pid }] } = await client.query("select pg_backend_pid() as pid");

signal.addEventListener(
  "abort",
  () => cancelPool.query("select pg_cancel_backend($1)", [pid]).catch(console.error),
  { once: true }
);

await client.query("select pg_sleep(3)"); // rejects with code 57014 when cancelled

[5256ms] api: pg_cancel_backend sent
[5257ms] api: query error -> 57014 canceling statement due to user request
[5570ms] DB: active pg_sleep queries 300ms after client left = 0

I left the rest of the handler out on purpose, because a half-finished copy of it is worse than none. The full handler, plus the Node 22 vs 24 screenshots, is in my longer write-up. The version I ran on Node 22 and 24 with Express 4.22.3 and 5.2.1 also does these things:

It uses a separate pool for cancels. With a work pool of 2 and two abandoned requests at once, I reproduced a hang. Both connections were held by handlers waiting on a cancel that needed a free connection.
It checks signal.aborted right after the pid query. If the deadline already fired, the listener above never runs. The client is still waiting, so the handler answers 504 itself.
It removes the listener and awaits any in-flight cancel before client.release(). Otherwise the connection can go back to the pool mid-cancel.
It catches 57014 and reads signal.reason. That code only means "cancelled". A deadline, a disconnect, statement_timeout or a DBA can all cause it, and the answer should be 504 only for the deadline.
It replies only if !res.destroyed && !res.writableEnded and sends everything else to next(err), since Express 4 doesn't catch rejected async handlers.
Both pools have on("error") handlers. Without them, one dropped idle connection can crash the process.

Treat the cancel as best effort. pg_cancel_backend returning true means the signal was sent. The Postgres protocol docs say a cancellation might or might not have any effect, for example when it lands after the query already finished, and the client can't directly tell which happened. With a pool, only cancel while your request still owns the connection. It also does nothing for a session sitting idle in a transaction, since there is no running statement.

Aborted doesn't mean undone

I ran a transaction that did an INSERT, spent one second on slow work, then COMMIT, and let the client leave at 300 ms. The naive handler committed an order for a user who was long gone. The cancel-aware handler caught 57014 and rolled back, so no row was written. The cancel only interrupts the statement. The rollback is yours to write.

The mirror image happens on the client. If you abort a POST, you can't know whether the server processed it, and a blind retry can create a duplicate. Put idempotency keys on anything with side effects.

You don't have to wait for the client to leave, either. Postgres has statement_timeout, and with 300 ms it raised 57014 after 307 ms. That covers the opposite problem, clients that never disconnect.

The limit: a blocked event loop can't be cancelled

JavaScript can't interrupt code that is already running. I ran a 1000 ms synchronous loop inside a handler and aborted the client at 200 ms. The server couldn't process the disconnect until the loop ended, and by then res.writableFinished was true. Node had written the response into a socket it hadn't yet noticed was closed, so even my own check couldn't tell the client had left.

If the work blocks the loop, there is nothing to cancel. Move it to a worker thread, or cut it into chunks with an await between them.

What I didn't test

Drivers other than pg, HTTP/2, reverse proxies and load balancers (a proxy may or may not tell your upstream that the client left), browsers, Deno and Bun.

Four rules I'd ship with

Treat a disconnect as an event. Listen for close on the response, check writableFinished, and pass one signal to everything that accepts it.
Cancel database work yourself when the driver won't. Check whether yours honors { signal } before you trust it, and keep cancels on their own pool.
Put a deadline on every request with a per-request AbortSignal.timeout() plus statement_timeout.
Make side effects safe. Roll back on cancel and use idempotency keys for retries.

The scripts behind every number are in a GitHub repo, if you want to rerun them.

I only tested pg. If you've checked how mysql2, Prisma or another driver treats an abort signal, tell me what you found in the comments.

React 19 useFormStatus Returning False? I Built a SubmitButton That Fixes It

Shubhra Pokhariya — Tue, 29 Sep 2026 08:13:20 +0000

A few weeks back I wrote about the useFormStatus bug that got me the hardest, the one where pending sits at false forever because the hook was called in the wrong component. If you haven't read that one, the short version is this: the hook only reports on a parent form, never one rendered by the same component calling it, and nothing warns you when you get it wrong. No error, no console message, the button just quietly never enters a pending state.

That post explained the bug. This one is about what I actually built once I got tired of re-explaining the same fix to myself on every new project, and about a second version of that exact same silent failure I didn't notice until I'd already shipped the first fix.

One scope note before the code: this fixes the placement mistake. If pending is false because the form submits through a plain onSubmit handler that only calls preventDefault(), or through a URL string action, moving the hook won't change anything, because there is no Action for it to track.

What the first post didn't cover

Moving the hook fixes the placement bug, but I ran into two more problems as soon as I used it in real forms.

The first is disabled={pending} on the button itself. It works, and it's also the wrong choice if you care about keyboard users. A disabled element drops focus the instant it becomes disabled. Someone tabs to your submit button, hits Enter, and focus jumps away mid submission, sometimes landing nowhere useful at all. The fix is aria-disabled instead of disabled, with the click blocked manually so repeat submissions still get ignored.

function SubmitButton({ children, pendingText, intent }) {
  const { pending } = useFormStatus();

  function handleClick(e) {
    if (pending) e.preventDefault();
  }

  return (
    <button
      type="submit"
      name={intent ? "intent" : undefined}
      value={intent}
      aria-disabled={pending || undefined}
      aria-busy={pending || undefined}
      data-pending={pending ? "" : undefined}
      onClick={handleClick}
    >
      {pending ? pendingText : children}
    </button>
  );
}

Focus stays exactly where it was. Style the pending state off aria-disabled or data-pending, not :disabled, since the native attribute is never actually set here.

The second problem shows up once a form has two submit buttons. pending belongs to the whole form, not to whichever button was clicked, so a Save Draft and a Publish button next to each other both light up for one click. The browser already knows which button submitted. Its name and value are in the FormData, so you read them back out and compare.

function useFormStatusForIntent(intent) {
  const status = useFormStatus();
  const submittedIntent = status.data?.get("intent");
  const isThisIntentPending =
    status.pending &&
    (intent === undefined || submittedIntent == null || submittedIntent === intent);
  return { ...status, isThisIntentPending };
}

<form action={savePost}>
  <textarea name="body" />
  <SubmitButton intent="draft" pendingText="Saving draft...">Save Draft</SubmitButton>
  <SubmitButton intent="publish" pendingText="Publishing...">Publish</SubmitButton>
</form>

The button shown earlier is simplified to keep the focus on aria-disabled. In the full file, SubmitButton calls this hook, so only the button someone actually pressed shows pending. One gotcha before you wire this up: pressing Enter in a text field submits through whichever button comes first in the markup. That's the HTML spec's definition of the default button, not something React decides. Put your safest action first.

Locking the rest of the form while it submits

Next you'll probably want the rest of the form locked while the request is in flight, so nobody edits a field mid submit. A native <fieldset> does this in one line instead of one disabled prop per input.

function PendingFieldset({ children, unstyled }) {
  const { pending } = useFormStatus();
  return (
    <fieldset
      disabled={pending}
      style={unstyled ? undefined : { border: 0, margin: 0, padding: 0 }}
    >
      {children}
    </fieldset>
  );
}

The unstyled flag is for CSP. The inline reset removes the fieldset's default border, but a CSP that blocks inline styles ignores it on server-rendered HTML and the border comes back. If that's you, pass unstyled and style it with a class.

One trade-off: a focused input loses focus when the fieldset disables it, the same thing that happens to a disabled button. Use it where blocking edits matters more than keeping focus.

For a screen reader announcement, aria-busy alone isn't read out loud. You need an actual live region for that.

function FormStatusText({ pendingText, idleText = null }) {
  const { pending } = useFormStatus();
  return (
    <span role="status" aria-live="polite" aria-atomic="true">
      {pending ? pendingText : idleText}
    </span>
  );
}

The bug I didn't catch until the second pass

Here's the part that made me go back and touch the file again after I thought it was already done.

SubmitButton had a dev-only check from the start. Render it outside a form and you get a console error in development explaining why it won't work.

PendingFieldset and FormStatusText had the identical requirement, "must be rendered inside the form", written right there in their own comments, but neither one actually had the check. Misplace either one and it fails as silently as the original bug: the fieldset never disables, the status message never appears, and nothing warns you.

It's an easy mistake to make, since these two feel less important than the submit button and tend to get dropped in wherever is convenient.

Both now run the same placement check the button already had, with the same escape hatch for anyone using a portal on purpose:

<PendingFieldset unsafeSkipFormCheck>
  {/* rendered through a portal: outside the form in the DOM, inside it in the React tree */}
</PendingFieldset>

The check has a limit. It only looks at the DOM, but useFormStatus follows the React tree. A component rendered through a portal can track the form correctly and still trigger the warning, because in the DOM it isn't inside the form. That's what unsafeSkipFormCheck is for.

Where this landed

The full file has the button, the fieldset, the live region, the intent hook, and the placement check on all three components. One file, no dependencies beyond react and react-dom.

Known limits: intent doesn't work with a per-button formAction, form.requestSubmit() skips the click guard, and two synchronous clicks in the same task both get through before React re-renders. I've only tested in Chromium and Firefox so far. Safari and screen readers are still untested.

If you want the whole thing: useFormStatus SubmitButton. Free, single file.

If you're catching this one first and want the full explanation of why the original bug happens, that's the earlier post.

React 19's useTransition Looked Simple. Then I Found a Second Bug Hiding Inside the First One

Shubhra Pokhariya — Mon, 21 Sep 2026 15:32:13 +0000

Every hook in this series so far has been a passenger. useActionState rides inside a Transition and reports back the result. useOptimistic rides inside one and shows you a preview before the real answer lands. useFormStatus doesn't even ride, it just reads a status from whoever else is driving. useTransition is the only one of the four that sits in the driver's seat by itself, no form required, no other hook required.

That's also why it's the easiest one to get partially right. You wrap a click handler in startTransition, you get an isPending flag, everything looks fine in your browser tab, and you ship it. Then someone double-clicks fast, or your function throws, or you try to hook it up to a text input, and the parts nobody mentioned start showing up.

This is a standalone guide. If you're new to this series, everything below works on its own. If you've read Part 4, you already saw useTransition make a brief appearance there through a wishlist button.

I tested every example below against React 19.2.8. I also re-ran the race condition, error boundary, and overlapping Transition checks on React 19.3.0, which shipped on September 9.

What useTransition Actually Gives You

Call it at the top of a component and you get back exactly two things, always in this order.

import { useTransition } from "react";

function ProductFilters() {
  const [isPending, startTransition] = useTransition();
  // ...
}

isPending is a boolean. It becomes true at the first call to startTransition, and stays true until every Action in that Transition, including anything you awaited, has completed and the resulting state is shown. startTransition is a function that takes one argument, a function of your own, and runs it right away. Nothing about startTransition is delayed or scheduled for later. What changes is how React treats any set call that happens while your function is running, those updates get marked as low priority and interruptible instead of urgent.

That's the entire contract. No result value, no built-in error state, no queue. Compare that to useActionState from Part 1, which hands you back whatever your function returns as state. useTransition doesn't do that. If your function returns something, that return value is simply gone unless you store it yourself. This is the tradeoff for using useTransition directly: less structure, but nothing standing between you and the raw mechanism.

A Search Filter That Doesn't Freeze the List

Forms and buttons aren't the only place a Transition earns its keep. Filtering a long list as someone types is a case useActionState was never built for, there's no side effect to run, no single result to track, just a rendered list that needs to stay responsive while it re-renders on every keystroke.

One precision point before the code: startTransition does not make a computation run in the background. The function you pass to it runs immediately and synchronously, right when you call it. What gets marked as low priority and interruptible is the state update, and the render that follows from it, not whatever JavaScript happens to run inside the callback before that update fires. That distinction is the whole point of this example, so the two state variables below are split around it deliberately.

import { useState, useTransition } from "react";

function ProductSearch({ products }) {
  const [query, setQuery] = useState("");
  const [filterQuery, setFilterQuery] = useState("");
  const [isPending, startTransition] = useTransition();

  function handleChange(e) {
    const value = e.target.value;
    setQuery(value);

    startTransition(() => {
      setFilterQuery(value);
    });
  }

  const filtered = products.filter((p) =>
    p.name.toLowerCase().includes(filterQuery.toLowerCase()),
  );

  return (
    <div>
      <input
        value={query}
        onChange={handleChange}
        placeholder="Search products"
      />
      <ul style={{ opacity: isPending ? 0.6 : 1 }}>
        {filtered.map((p) => (
          <li key={p.id}>{p.name}</li>
        ))}
      </ul>
    </div>
  );
}

query drives the input and updates synchronously, so typing never lags. filterQuery is the one wrapped in startTransition, it "lags behind" query on purpose. filtered isn't stored in state at all, it's a plain expression computed fresh on every render from filterQuery. The key point: the products.filter() call itself still runs as an ordinary, uninterrupted piece of JavaScript, exactly like it would outside a Transition. What changed is when that render happens and whether a more urgent update, another keystroke, is allowed to cut in front of it. React isn't chunking your array iteration, it's deciding whether the render containing that iteration gets to proceed right now or gets pushed behind something more urgent.

This is also where the input-in-a-Transition limitation becomes concrete instead of abstract. You cannot wrap query itself in startTransition, only filterQuery can go there. A controlled input's value has to update synchronously with every keystroke to feel correct, and React's own troubleshooting docs name this exact two-state split as one of two fixes, the other being useDeferredValue on a single state variable.

When to reach for useDeferredValue instead. The rule of thumb is about who owns the set function. Here, the component owns setFilterQuery directly, so useTransition is the right tool. If ProductSearch instead received its query as a prop from a parent, or read it from some other hook you don't control the setter for, there'd be no set call of your own to wrap in startTransition. That's exactly the case useDeferredValue exists for, you hand it the value, const deferredQuery = useDeferredValue(query), and it produces its own lagging copy without needing access to whoever's setting the original. Same lagging behavior, different entry point depending on whether you're driving the update or just receiving the value.

The await Rule, and Why It Actually Happens

Part 4 showed the pattern for handling state updates after an await inside a Transition, wrap them in a second startTransition call. What it didn't get into is why React needs that second call at all, and that's worth understanding once instead of memorizing as a rule.

function handleSave() {
  startTransition(async () => {
    const saved = await saveDraft(draft);
    // this update is NOT part of the Transition
    setStatus("saved");
  });
}

React marks a set call as part of a Transition by checking a flag while your function is running synchronously. The moment your function hits await, execution yields back to the JavaScript engine, and that flag is gone by the time the code after await resumes. React has no way to know that resumed code is a continuation of the same Transition rather than something unrelated. This is a JavaScript limitation, not a bug React chose not to fix, the language doesn't yet give React a way to track "this async continuation belongs to that earlier synchronous scope." A TC39 proposal called AsyncContext would close this gap, but it isn't part of the language yet.

The fix is the same nested call every time.

function handleSave() {
  startTransition(async () => {
    const saved = await saveDraft(draft);
    // ✅ back inside a synchronous startTransition scope
    startTransition(() => {
      setStatus("saved");
    });
  });
}

After every await, state updates that need to remain part of the Transition must be wrapped in another startTransition, as the useTransition docs describe. Two sequential awaits in one Action means two separate re-entries into startTransition for the updates that follow each one.

Pending UI With No Form in Sight

Every pending indicator earlier in this series read isPending from useActionState or pending from useFormStatus. useFormStatus reads from a parent form, and useActionState is built around the Actions you dispatch through it. useTransition's isPending is the one you get when you start the Action yourself, with no form involved. It's just a boolean tied to whatever you wrapped, which means it works for things that were never going to be a form to begin with: a favorite toggle, a sort order change, a modal that loads data before it opens.

function SortButton({ label, sortKey, onSort }) {
  const [isPending, startTransition] = useTransition();

  return (
    <button
      disabled={isPending}
      onClick={() => startTransition(() => onSort(sortKey))}
    >
      {label}
      {isPending && <span className="spinner" aria-hidden="true" />}
    </button>
  );
}

The button that triggered the change is the one that shows its own pending state, without a global loading flag and without prop drilling a status down from somewhere else. That's the same locality useFormStatus gave you in Part 3, just reached through a different door, one that doesn't require a <form> to walk through.

Errors in a Bare Transition

This is the gap Part 4 didn't touch, and it's a real one. useActionState gives you a place to catch expected errors as returned state. A bare useTransition call gives you nothing like that. If the function you pass to startTransition throws, there's no result state to inspect, the throw propagates up to the nearest error boundary instead.

import { useTransition } from "react";
import { ErrorBoundary } from "react-error-boundary";

function AddToCartButton({ productId }) {
  const [isPending, startTransition] = useTransition();

  function handleClick() {
    startTransition(async () => {
      const result = await addToCart(productId);
      if (!result.ok) {
        throw new Error("Could not add item to cart");
      }
    });
  }

  return (
    <button disabled={isPending} onClick={handleClick}>
      Add to Cart
    </button>
  );
}

export function CartButtonWithBoundary(props) {
  return (
    <ErrorBoundary fallback={<p>Something went wrong adding this item.</p>}>
      <AddToCartButton {...props} />
    </ErrorBoundary>
  );
}

Worth being clear about what's actually happening here: useTransition doesn't give you a custom error state or a new API surface for errors, that part is true. But it's not accurate to call this identical to any ordinary render-time error either. React specifically added Error Boundary support for Actions, so a throw inside startTransition gets caught the way a throw in a plain event handler normally wouldn't, event handler errors have never been something a boundary catches on their own.

Two things trip people up here. First, the error boundary has to wrap the component calling useTransition, not just the button markup, an error boundary placed below the hook call won't catch anything. Second, this is an all-or-nothing tool: a thrown error takes down whatever the boundary wraps until the user or your code resets it. If you want a recoverable, inline error message instead of the whole section replaced by a fallback, don't throw, return an error value from the function and store it in state yourself. useActionState gives you that pattern for free, since its return value becomes state automatically. Plain useTransition doesn't, you'd be rebuilding a small piece of what useActionState already does.

The Race Condition Nobody's First Draft Handles

Here's the scenario Part 4 flagged and left open. A user clicks something that triggers an async Transition, changes their mind, and clicks again before the first request resolves. Both requests are now in flight. The response that arrives last is the one the component keeps, even if it belongs to the earlier click.

import { useState, useTransition } from "react";

function QuantityStepper({ itemId, initialQty }) {
  const [qty, setQty] = useState(initialQty);
  const [isPending, startTransition] = useTransition();

  function updateQty(next) {
    startTransition(async () => {
      const saved = await updateCartQuantity(itemId, next);
      startTransition(() => {
        setQty(saved);
        // if a slower, earlier request resolves after this one,
        // its setQty runs last and the stale value wins
      });
    });
  }

  return (
    <div>
      <button onClick={() => updateQty(qty - 1)}>-</button>
      <span>{qty}</span>
      <button onClick={() => updateQty(qty + 1)}>+</button>
    </div>
  );
}

React's own reference material for this exact scenario says it plainly: Actions inside a Transition don't guarantee execution order once you await something, because the async boundary loses that ordering context the same way it loses the Transition flag. useActionState sidesteps this for its own dispatcher by queuing calls and running them one at a time, but a raw useTransition call gets no such protection.

There's actually a second problem hiding in this code, and it's easy to miss because it looks like the same bug. updateQty(qty - 1) reads qty from the render that produced this particular click handler, and setQty only fires once the network request resolves. Click + twice within that window, before the first request's response has actually come back and updated qty, and both clicks compute their next value from the same starting number, sending the same result twice instead of incrementing twice. This isn't a same-tick React batching quirk, clicks are handled as separate events and React doesn't merge them. It's simpler and more common than that: the state genuinely hasn't changed yet, because the only thing that changes it is still sitting on the wire. Fixing the request race doesn't fix this one, they need separate solutions.

import { useState, useTransition, useRef } from "react";

function QuantityStepper({ itemId, initialQty }) {
  const [qty, setQty] = useState(initialQty);
  const [isPending, startTransition] = useTransition();
  const requestedQty = useRef(initialQty);
  const latestRequestId = useRef(0);

  function updateQty(delta) {
    // authoritative next value, independent of what's currently rendered
    requestedQty.current += delta;
    const next = requestedQty.current;
    const requestId = ++latestRequestId.current;

    startTransition(async () => {
      const saved = await updateCartQuantity(itemId, next);

      startTransition(() => {
        // only apply this result if nothing newer has been fired since
        if (requestId === latestRequestId.current) {
          setQty(saved);
        }
      });
    });
  }

  return (
    <div>
      <button onClick={() => updateQty(-1)}>-</button>
      <span>{qty}</span>
      <button onClick={() => updateQty(1)}>+</button>
    </div>
  );
}

Two separate fixes doing two separate jobs. requestedQty is a ref that tracks the next value to send independently of the rendered qty, so it keeps accumulating correctly across rapid clicks no matter how far behind the actual render is. latestRequestId is the token that solves the original problem, a stale response checks whether it's still the most recent request before it's allowed to apply. A ref is the right tool for both because neither one needs to trigger a render on its own, they just need to survive across renders and stay current. This isn't the only way to solve the ordering half, an AbortController tied to each request works too if your fetch layer supports cancellation, though aborting only stops the client from waiting, and the server may already be processing that mutation. The token check needs nothing from your API beyond what you probably already have.

Two limits worth knowing. requestedQty advances at click time, so it assumes the server accepts the requested value as sent. If the server clamps or normalizes that value, the ref and qty can drift apart. The request token only decides which response can update the UI. It doesn't cancel the earlier request or guarantee that the server applies the updates in the order they were sent.

When to Reach for useTransition and When Not To

Reach for it when you need pending tracking for something that isn't a form submission and doesn't need a tracked result value: filtering, sorting, tab switches, toggles, navigation.

Don't reach for it for a controlled input's own value, that has to stay synchronous or typing will visibly lag. Don't reach for it when you need the function's return value as state, that's what useActionState captures automatically and useTransition doesn't. Don't reach for it assuming request ordering is handled, it isn't, not without the token pattern above or an equivalent.

Keep in mind that the useTransition reference still lists a limitation: if multiple Transitions are ongoing, React currently batches them together. React 19.3 changed something nearby. According to the React 19.3 release post, a Transition with a slow render no longer holds up unrelated ones. So don't assume several pending indicators settle independently.

Where This Leaves the Series

You need to...	Reach for
Own a form's result and pending state in one place	`useActionState`
Show finished UI before a server response confirms it	`useOptimistic`
Read a form's pending state from a component that isn't managing it	`useFormStatus`
Run pending-tracked work outside a form, with full control yourself	`useTransition`

Part 4 called these four answers to four different questions sharing one mechanism. Having now used the fourth one without any of the other three in the room, that framing holds up. useTransition isn't the beginner-friendly entry point of the group, it's the one with the fewest guardrails, which is exactly why it's also the one that can do things the form-shaped hooks were never built for.

I went through the out-of-order version of this bug in a plain search box in I Throttled My App to Slow 3G. Here's What My Tests Never Caught.

So which one have you already shipped without knowing it, a response landing out of order or two fast clicks reading the same stale value? Drop it below.

The Code I Couldn't Leave Alone

Shubhra Pokhariya — Thu, 17 Sep 2026 12:20:21 +0000

The bug report was simple enough. On the reports dashboard, if you changed the date range while a filter was already active, the page number didn't reset. So a user could end up on page 4 of a report that now only had one page of results, staring at an empty table with no idea why.

I found it fast. The pagination state and the filter state were living in two different places, useState in the table component and useSearchParams for the filters, and nothing was watching one to reset the other. I added a useEffect that reset the page to 1 whenever the search params changed. It was the smallest change that unbroke the dashboard, and I wasn't about to restructure the component tree for a twenty minute fix. Tested it locally, clicked through a few filter combinations, watched the empty table problem disappear. Twenty minutes, maybe less.

I didn't open the pull request yet. I told myself I wanted to read through the diff once more before pushing.

That's when I actually looked at ReportFilters.tsx for the first time in a while, and I didn't love what I saw. The filter state existed in two places at once. Some of it lived in the URL through useSearchParams, which is what actually drove the API call, and some of it lived in local component state that only existed to control what the dropdowns displayed. Most of the time they matched. Occasionally, if you clicked fast enough, they didn't, and you'd see a dropdown showing one filter while the table quietly fetched with another. Nobody had filed a bug for that. I don't think anyone had ever managed to click fast enough to notice.

But I'd noticed it now, and once you've seen a bug like that, it's hard to unsee it. It reminded me of a race condition I once tracked down in a checkbox that looked right on screen while the requests behind it quietly disagreed, the same kind of mismatch between what the UI shows and what actually happened. Different bug, same shape.

So I pulled the local state out entirely and made the URL params the single source of truth, reading everything through useSearchParams and writing through router.replace. That's a real fix. Two sources of truth for the same data is exactly the kind of thing that eventually causes a much worse bug than the one I'd started with. I felt good about that change, and I still do.

While I was in there, I noticed the filter logic itself, the actual function that turned the search params into a query object, was duplicated. It existed once in the component to build the fetch request, and again inside app/api/reports/route.ts to validate incoming params on the server. Same logic, written twice, slightly out of sync, because someone had updated one copy when a new filter type was added and forgotten the other. I pulled it into a shared lib/filters.ts and imported it in both places. That's not a nice to have. That's the kind of drift that can quietly turn into a production bug.

At this point I'd fixed the original bug, removed a genuine duplicate source of truth, and closed a real gap between client and server validation. If I'd stopped there, this would just be a normal Tuesday. I didn't stop there.

Once the filter logic was centralized, I looked at the route handler again and thought, well, since I'm already reading through this, the report data itself doesn't actually need to be client fetched at all. It's not interactive in any way that requires it. It could be a server component, fetched directly with the filters coming from searchParams in the page props, no client-side fetch, no loading spinner, no waterfall. In my head it looked roughly like this.

export default async function ReportsPage({
  searchParams,
}: {
  searchParams: Promise<{ range?: string; status?: string }>;
}) {
  const { range, status } = await searchParams;
  const reports = await getReports({ range, status });
  return <ReportsTable data={reports} />;
}

That's a bigger change than a bug fix. It touches the page structure, it means rethinking how the table gets its data, it means the loading state disappears entirely because the server just renders with the data already there.

I started doing it anyway.

I got about halfway through converting the table to a server component before I stopped, not because it was going badly, but because I glanced at the git diff panel in my editor and the file count had gone from one changed file to seven. Seven files, for a bug that was, structurally, a missing line inside a useEffect.

I sat there for a second looking at that number, and the question that actually stopped me wasn't "is this too much work." It was smaller and quieter than that. I asked myself whether the server component conversion was something the product needed right now, or whether it was something I wanted to do because I could see exactly how to do it and it bothered me to leave it undone once I'd seen it.

I didn't have a clean answer immediately, which is honestly what made me pay attention. The filter state fix and the duplicated logic fix, I could justify those in one sentence each, to myself or to a reviewer. The server component rewrite took a full paragraph to justify, and most of that paragraph was about how satisfying the final version would be, not about what was currently broken for anyone using the dashboard.

That's usually the tell, I think. Not the size of the change. Plenty of small changes are indulgent and plenty of large ones are necessary. It's how long the justification takes, and who the justification is actually for.

So I split it. I finished the bug fix and the shared filter logic, wrote a focused pull request that a reviewer could read in five minutes and understand completely, merged it the same day. The server component rewrite went into its own branch with its own description, explaining what it would remove, what it would simplify, and why it was worth doing on its own terms instead of riding in quietly behind a one-line bug fix. It's a good change. I still believe that. It just needed to stand on its own, reviewed and evaluated as what it actually was, instead of hiding inside something smaller.

What stays with me isn't that I almost shipped too much. It's how reasonable every single step felt while I was inside it. Nobody would have blinked at any individual commit. The dropdown desync fix, obviously worth doing. The shared filter util, obviously worth doing. Even the server component conversion, on its own merits, was obviously worth doing. Stacked together in one sitting, driven by one bug report, they stopped being a response to a problem and became a response to my own discomfort with leaving the file the way I found it.

I don't think that discomfort is something to train out of myself. It's most of why I'm good at this. Being able to see the second problem while you're fixing the first one is a real skill, and I'd rather have it than not. But seeing a change and shipping a change used to be the same motion for me, and somewhere in that two hour stretch I finally felt the gap between them instead of just hearing about it in theory.

I closed the laptop that evening having shipped exactly one thing, a twenty minute bug fix with a real structural improvement folded honestly into it. The bigger rewrite is sitting in review on its own branch, where it belongs, where someone can actually look at it and ask whether it's worth the seven files, instead of me deciding that alone at ten at night because I couldn't stand leaving a route handler half server, half client, one more day.

I Throttled My App to Slow 3G. Here's What My Tests Never Caught

Shubhra Pokhariya — Tue, 15 Sep 2026 05:41:21 +0000

I wasn't looking for a performance problem. I wanted to see what happened when the network got slow enough that assumptions I normally never notice had time to surface. So I opened DevTools, set the throttle to 3G (Chrome's network throttling reference dropped the separate "Slow 3G" preset a while back and just calls it "3G" now, sitting between Slow 4G and Offline), and started clicking around an app that had never once misbehaved on my normal wifi.

Two things broke. Both were correctness bugs, not "feels slow" complaints, and both were sitting in code that had passed every test I'd written for it.

Bug one: a race condition, search results arriving in the wrong order

The app has a search box. Type a query, it fetches results, it shows them. Nothing fancy:

async function search(query) {
  const res = await fetch(`/api/search?q=${query}`);
  const data = await res.json();
  setResults(data.results);
}

This is a race condition, and on fast wifi you'll rarely notice it, because request and response times are close enough together that ordering rarely flips. That's not a guarantee, it's just what low, consistent latency looks like most of the time. Slow the connection down and that stops holding. If you type "apple", pause, then quickly change it to "banana", the "apple" request and the "banana" request are both in flight at once. Whichever one happens to take longer, maybe it hit a slower part of the network, maybe the server did more work for it, can land after the other one. When it does, its response overwrites the screen with results for a query you're not even looking at anymore.

If this sounds familiar, I went through a close cousin of this bug in The Optimistic UI Race Condition That Only Showed Up on the Fifth Click, stale results from out-of-order requests aren't unique to search boxes, they show up anywhere a component fires more than one async request over its lifetime.

The 3G throttle on its own makes this easier to hit, since it throttles every request in the session regardless of which path it takes. But it doesn't guarantee a flip on any given run, so to make it reproducible for this post I forced it deterministically: I gave the two queries different artificial delays on the server, apple takes 3 seconds, banana takes 200 milliseconds. That's a server-side delay, not the network throttle. For the logs and timings below, I ran the test with throttling off so the numbers are clean and come from the server delay alone. With throttling on, the same race still happens, but the network adds less predictable latency on top, which makes the timing harder to read in a screenshot.

Click apple, then banana right after.

sent request for "apple"
sent request for "banana"
got response for "banana" after 210ms
got response for "apple" after 3001ms

The screen ends up showing apple's results, because that's whichever response arrived last, not whichever request the user cared about last.

The fix is to stop trusting arrival order and start tracking which request is actually the latest one:

let latestQueryId = 0;

async function search(query) {
  const thisId = ++latestQueryId;
  const res = await fetch(`/api/search?q=${query}`);
  const data = await res.json();
  if (thisId !== latestQueryId) return; // a newer request has already been sent
  setResults(data.results);
}

Same two requests, same order of arrival, one result on screen:

sent request for "apple" (id 1)
sent request for "banana" (id 2)
got response for "banana" (id 2) after 210ms
got response for "apple" (id 1) after 3001ms
   IGNORED: a newer request has been sent since this one fired

Another option is AbortController, which can abort the previous fetch when a new query starts. That's a different tradeoff from request IDs, not the same mechanism wearing a different name. Aborting stops the client-side fetch from continuing to wait on that response. It doesn't necessarily stop the server from finishing the work it already started. Tracking request IDs instead lets the old request finish, then explicitly ignores its response if it's gone stale. I went with request IDs here because the search endpoint is cheap and I didn't need to cancel anything server-side, just make sure a late response can't win.

Bug two: the autosave that saves twice, or drops your last edit

This one comes from a client-side timeout that assumed a round trip would always be fast.

The autosave gave up and retried if it hadn't heard back within 1.2 seconds, a reasonable number if saves normally take a few hundred milliseconds. On a throttled connection a save can genuinely take two or three seconds without anything actually being wrong. The client can't tell "slow" apart from "failed." It just knows the timer ran out, assumes the worst, and fires a second save while the first one is still in flight and about to succeed on its own.

save #1 sent
save #1 client-side timeout, treating as failed and retrying
save #2 sent
save #1 confirmed (arrived after the retry already fired)
save #2 confirmed

Two saves for one edit. If the save endpoint isn't strictly idempotent, that's two writes that can produce different results depending on what changed in between, not just a harmless duplicate.

My first fix was a simple in-flight guard: skip firing a new save while one is already out. That stops the duplicate, but it introduces a different bug. If you edit again while a save is in flight, that edit gets silently dropped instead of ever being sent:

user types "hello", save #1 starts
user types "hello world" while save #1 is still in flight
   skipped (save in flight), edit "hello world" is dropped
save #1 confirmed: "hello"

For this autosave behavior, the version you want doesn't skip the newer edit, it queues it and sends it right after the current save finishes:

let saveInFlight = false;
let pendingContent = null;

async function save(content) {
  if (saveInFlight) {
    pendingContent = content;
    return;
  }
  saveInFlight = true;
  try {
    await postSave(content);
  } finally {
    saveInFlight = false;
  }
  if (pendingContent !== null) {
    const next = pendingContent;
    pendingContent = null;
    await save(next);
  }
}

The try/finally matters here, not just style. Without it, if postSave ever rejects, saveInFlight stays true forever and every future edit gets silently queued and never sent. That's a worse bug than the one you started with, because it fails quietly.

save #1 sent: "hello"
skipped (save in flight), queued latest: "hello world"
save #1 confirmed: "hello"
save #2 sent: "hello world"
save #2 confirmed: "hello world"

No duplicate requests, and the latest edit still gets saved. (If you edit again while that queued save is itself in flight, it just replaces pendingContent again, that's the coalescing working as intended, only ever the most recent edit waits in line.) This is the simple version of the queueing strategy, worth saying plainly: a production autosave also needs an explicit policy for what happens when a save actually fails, not just when it's slow. This code handles slow, not failed.

The actual lesson here isn't "guard against duplicate saves", it's that a client-side timeout only tells you a response hasn't arrived yet. It doesn't tell you what happened on the server, and if the operation has side effects, retrying it needs an explicit strategy for what happens to work that's already in flight.

What both actually have in common

I didn't go looking for two bugs about ordering and timing specifically. I went looking for whatever would show up if I stopped assuming my network was representative of anyone else's. Both of these surfaced because each one was built around an assumption that happened to hold on my machine and broke somewhere else. Responses usually arrive in the order you send them, until they don't. A couple seconds is usually enough time for a save to complete, until it isn't.

Neither of my test suites caught either of these, because neither ran on a slow connection. They ran on the same fast, forgiving network I was developing on, which is exactly the network that hides both of these bugs. Same pattern I ran into with a completely different upgrade in Next.js 16 Broke My App in 4 Places and None of Them Threw an Error, none of these bugs throw, none of them fail loud, they just quietly do the wrong thing until you go looking under the exact condition that triggers them.

If your code assumes responses arrive in request order, or treats a client timeout as proof of failure, you likely have a version of one of these sitting in code you already trust, whether or not you've seen it misbehave yet.