Issue with Server Actions + useTransition hanging indefinitely

[tomarrohitt]

Summary

I’m running into a specific issue where my UI gets stuck in a pending state after a Server Action completes. The backend updates successfully, but the UI does not update until I manually reload the page.

This issue is intermittent. It works correctly about 7 out of 10 times, but the other 30% of the time the useTransition hook never resolves, leaving the spinner spinning indefinitely.

Context:
Next.js version: ^16.0.10
ENV: build/production (in dev it is working fine)
Architecture: a Client Component (CartQuantity) triggers a Server Action (updateCartItem).
Key config: I am using cacheComponents: true in next.config.ts.

cart-quantity.tsx
"use client";
import { updateCartItem } from "@/actions/cart";
import { useTransition } from "react";
// ... imports

export const CartQuantity = ({ item }: { item: CartItemWithProduct }) => {
  const [pending, startTransition] = useTransition();

  const handleQuantityChange = (quantity: number) => {
    if (pending) return;

    startTransition(async () => {
      // The await completes, but the transition doesn't seem to "finish"
      await updateCartItem(item.productId, item.quantity + quantity);
    });
  };

  return (
    <div className="flex items-center space-x-2">
       {/* ... buttons ... */}
      <span className="w-12 text-center font-bold">
        {pending ? <Loader2 className="animate-spin" /> : item.quantity}
      </span>
       {/* ... buttons ... */}
    </div>
  );
};

// action.ts
"use server";
import { revalidatePath } from "next/cache";

export async function updateCartItem(productId: string, quantity: number) {
  try {
    await api.patch(`/cart/${productId}`, { quantity });

    // This runs successfully on the server
    revalidatePath("/cart");
  } catch (error) {
    console.error("Error updating item in cart:", error);
  }
}


// logs from the backend


api-gateway:dev: PATCH /api/cart/id... 200 15ms
api-gateway:dev: GET /api/cart/count 200 8ms
api-gateway:dev: GET /api/cart 200 11ms

What happens: I click the generic +/- button, startTransition triggers the Server Action, the backend succeeds. My API gateway logs show the PATCH was successful and the subsequent GET requests (triggered by revalidation) return 200 OK with the new data. But on the frontend, the pending state from useTransition remains true and the UI never updates with the new quantity.

This issue seems specific to aggressive production caching. It works perfectly in development but fails intermittently in production builds.

What I tried that did not fix it:

1. revalidatePath("/cart") (server cache is purged but client doesn’t pick it up)
2. router.refresh() in the client after the action, redirect() to force navigation, and refresh() from next/cache on the action side.

Nothing breaks the pending state or forces the UI to render the new server value when cacheComponents is enabled.

Has anyone seen useTransition hang specifically when component caching is enabled? Is there a proper way to bust the client-side router cache in this setup? I’ve been stuck on this since yesterday morning and could really use some insight.

output.mp4

Additional information

No response

Example

No response

[pouriya73]

Hi @tomarrohitt

Client Component

"use client";
import { updateCartItem } from "@/actions/cart";
import { useTransition } from "react";

export const CartQuantity = ({ item }) => {
  const [pending, startTransition] = useTransition();

  const handleQuantityChange = (quantity: number) => {
    if (pending) return;

    startTransition(async () => {
      await updateCartItem(item.productId, item.quantity + quantity);
    });
  };

  return (
    <span>
      {pending ? <Loader2 className="animate-spin" /> : item.quantity}
    </span>
  );
};

Server Action

"use server";
import { revalidatePath } from "next/cache";

export async function updateCartItem(productId: string, quantity: number) {
  await api.patch(`/cart/${productId}`, { quantity });
  revalidatePath("/cart");
}

⚠️ Avoid this pattern

startTransition(async () => {
  await serverAction();
});

✅ Safer pattern

setLoading(true);
await serverAction();
setLoading(false);

[tomarrohitt]

@pouriya73 Yeah run it. The issue still persist.

[pouriya73]

@tomarrohitt
In that case, we need to review the entire project in detail.

[tomarrohitt]

@pouriya73 Thankyou very much.

[tomarrohitt]

@pouriya73

One thing I want to mention.
Imagine I have multiple items in the cart. When I update one item, like increasing its quantity or removing it, the API call succeeds, but the UI gets stuck. The spinner keeps spinning and the UI does not update.

However, if I then interact with another item in the cart, like increasing its quantity or removing it, the UI suddenly updates and reflects the previous change as well. So the backend is working correctly, but the UI only re-renders when a second interaction happens.

Screencast_20260120_190834.webm

[gaearon]

Just wanted to mention that this is not correct:

This happens because useTransition is not actually tracking the server action itself, but whether React commits a new UI update. In production, when aggressive caching like cacheComponents: true is enabled, Next.js may decide that no new client tree needs to be committed (or it gets stuck behind a cached/suspense boundary), so the transition never “finishes” even though the server action and revalidation succeed. In development this is masked because caching is looser and extra renders happen, but in production the stricter cache + router behavior can leave pending stuck true even after the backend work is done.

Transitions should not get stuck. This is either a Next or a React bug.

[Nielsen642]

Hey @tomarrohitt
You must force a client navigation refresh that bypasses the router cache.
startTransition(async () => {
await updateCartItem(...);
router.refresh(); // required to bust router cache
});
revalidatePath() only clears server cache – it does NOT refresh the client router.
I hope my solution help

[tomarrohitt]

Hey @tomarrohitt You must force a client navigation refresh that bypasses the router cache. startTransition(async () => { await updateCartItem(...); router.refresh(); // required to bust router cache }); revalidatePath() only clears server cache – it does NOT refresh the client router. I hope my solution help

@Nielsen642 I have tried router.refresh(), redirect and refresh() from "next/cache" nothing seem to be working.

[Nielsen642]

@tomarrohitt, thanks for your response.
I recommend setting it as follows:
export const dynamic = "force-dynamic" or cacheComponents: true

Disable caching for that path.
I've previously used this method to resolve this issue 100% successfully with useTransition.

[tomarrohitt]

@Nielsen642
Unfortunetely it is not working. I have tried everything related to cache stuff this must have something to do with UI update.

[tomarrohitt]

For anyone else pulling their hair out over this, it turns out this is not an issue with your code,revalidatePath, or the Next.js Cache configuration.

The Root Cause: This is a binary-level race condition in the React 19 Fiber Reconciler (specifically regarding resolveLazy and useId replay tracking). When a Server Action resolves very quickly, the reconciler marks the boundary as suspended but fails to "replay" the update to the DOM, leaving the UI stuck in a pending state even though the data has arrived on the client.

The issue was introduced in Next.js commit that upgraded React from eaee5308-20250728 to 9be531cd-20250729. Which was fixed in a React Patch on Jan 17, 2026.

#86055
react/react#35399

This is tracked in commit that created the issue in NextJs e5c1dff8262b4d7dcef5bda0af9d9171196457bd

The Fixes:
I tested multiple approaches. You have two options depending on your risk tolerance:
Option 1: If you must use Next.js 16, you cannot stay on the stable release (as of this comment) because it bundles the affected React binary. You must force-install the specific React Canary build that contains the fix:
Bash

npm install next@canary react@canary react-dom@canary --force
Note: Ensure the installed react-dom version hash is from Jan 19, 2026 or later.

Option 2: What I did Since next@canary can be unstable for production, the safest path is to remove the buggy React 19 engine entirely. I downgraded to Next.js 15.3.6 and react 19.0.0
Result: The race condition does not exist in React 19.0.0 and React 18 The spinner works perfectly every time.

Security Note: If you downgrade, make sure to use next@15 (not an old specific patch) to ensure you are covered against CVE-2025-66478.

TL;DR: It's a React 19 bug . Upgrade to the absolute latest Canary or downgrade to React 19.0.0 (Next.js 15 or Next.js 14) to solve it. Don't waste time debugging your revalidatePath logic.

[andrewgreenh]

Is this still relevant with React DOM 19.2.4 (release on 2026-01-26)?
I still see exactly this pattern...

[tomarrohitt]

Yes, this still appears to be relevant for React DOM 19.2.4 (released on 2026-01-26).

The fix was merged on January 16, but it does not seem to be included in the v19.2.4 release tag. When checking the commit directly:

react/react@5f9a809

GitHub shows: “This commit does not belong to any branch on this repository…”

Additionally, comparing the stable tag against main indicates that the fix exists in main but is not part of the v19.2.4 lineage:

react/react@v19.2.4...main

So although the patch landed in canary on January 16, it does not appear to have shipped in the 19.2.4 stable release. That would explain why the same behavior is still reproducible on 19.2.4.

If the fix is required immediately, the only options are to use a canary build (not recommended for serious apps) or wait for the next stable release that includes the commit or you can downgrade to next 15 or v14.

[Hanskrogh]

We have tried the canary version of both nextjs and react - it seems to have gotten better, but it is still reproducible.

[tomarrohitt]

In that case downgrade to Next 15 is the only option.

Security Note: If you downgrade, make sure to use next@15 (not an old specific patch) to ensure you are covered against CVE-2025-66478.

[gaearon]

If you can prepare a reproducing case with the latest canary, please file a bug and I'll take a look.

[pinecodex]

Data point as requested upthread: we reproduce this exact symptom (form action via useActionState completes server-side — HTTP 200 with the action result and revalidated RSC tree in the Flight payload — but the client never commits; isPending stuck forever, main thread idle, prod builds only, intermittent ~1/6 CI runs, bundle-layout-sensitive) on Next 16.2.9/16.2.12/16.3.3, whose vendored React is 19.3.0-canary-3f0b9e61-20260317 — i.e. already including react/react#35518. So either the fix is incomplete or there is a second race with the same signature.

Full details, statistics from repeated-fresh-build sampling, and what we ruled out: #97990 — happy to run instrumented builds and share Playwright traces.