RSC table inside Parallel + Intercepted Route modal does not re-render after Server Action + revalidateTag/revalidatePath on first hard navigation (Next.js 15.4.4)

[GianBaeza]

Description

When using Parallel Routes + Intercepted Routes to render a modal that
contains an RSC table, the table does not refresh after a Server Action
is executed on the first hard navigation (direct URL access or page reload
in a deployed environment). The issue does not reproduce locally or with
Docker.

Environment

• Next.js version: 15.4.4
• React version: 19
• Deployment: Custom server (deployed environment, not Vercel)
• Local behavior: Works correctly (Docker + local dev server)
• Deployed behavior: Fails on first hard navigation only

Route structure

app/
├── gestionUsuario/
│   ├── page.tsx                        ← User list (RSC)
│   ├── @modal/
│   │   └── (.)editar/
│   │       └── [id]/
│   │           └── page.tsx           ← Intercepted modal (RSC)
│   └── editar/
│       └── [id]/
│           └── page.tsx               ← Real route fallback

What happens

1. User navigates to /gestionUsuario (user list)
2. User opens a user detail → navigates to /gestionUsuario/editar/[id]
   → intercepted route renders as a modal ✅
3. Inside the modal, there is an RSC table that fetches data via a
   Server Action
4. User triggers an action (e.g. assign a role) → Server Action runs
   → revalidateTag is called → router.refresh() is called on the client
5. The table does not re-render with the new data ❌

This only happens on the first hard navigation to the app in a
deployed environment. On subsequent soft navigations, it works correctly.

Reproduction steps

1. Deploy the app (not local)
2. Open the browser on a fresh session (no router cache)
3. Navigate directly to /gestionUsuario
4. Open a user modal → /gestionUsuario/editar/[id]
5. Trigger a Server Action that calls revalidateTag + router.refresh()
6. Observe that the RSC table inside the modal does not update

Code

Server Action:

export const server_AsignarRol = async (
  usuarioId: string,
  sistema: { client_id: string; role_name: string }
): Promise<ServerResult<null>> => {
  const result = await fetchServer<null>(`${URL_ASIGNAR_ROL}/${usuarioId}`, {
    method: "PUT",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(sistema),
  });

  if (result.ok) revalidateTag(`usuario-detalle-${usuarioId}`);
  return result;
};

RSC fetch with tag:

export const server_ObtenerUsuarioPorId = async (id: string) => {
  return fetchServer<UsuarioCompleto>(`${URL_USUARIO_DETALLE}/${id}`, {
    method: "GET",
    next: { tags: [`usuario-detalle-${id}`] },
  });
};

RSC table body:

export default async function TablaBodySistemasEditar({ 
  idUsuario 
}: { 
  idUsuario: string 
}) {
  await sleep(1000); // intentional delay for skeleton
  const result = await server_ObtenerUsuarioPorId(idUsuario);
  const sistemas = (result.data as UsuarioCompleto)?.permisos ?? [];

  return (
    <tbody>
      {sistemas.map((sistema, index) => (
        <tr key={index}>
          <td>{sistema.client_id}</td>
          <td>{sistema.role_name}</td>
        </tr>
      ))}
    </tbody>
  );
}

Table wrapper with Suspense key:

export default function TablaSistemasEditar({ 
  idUsuario, 
  searchParams 
}: { 
  idUsuario: string;
  searchParams: { [key: string]: string | string[] | undefined };
}) {
  return (
    <Suspense
      key={JSON.stringify(searchParams)} // key changes to trigger re-render
      fallback={<SkeletonTabla columnas={3} filas={3} />}
    >
      <TablaBodySistemasEditar idUsuario={idUsuario} />
    </Suspense>
  );
}

Client button:

const handleAccion = async () => {
  await server_AsignarRol(idUsuario, { client_id, role_name });
  router.refresh();
};

Root cause (hypothesis)

On hard navigation (first render, no in-memory router cache), Next.js
cannot determine the active state of the Parallel Route slots. The RSC
payload for the intercepted modal is served correctly, but after
revalidateTag + router.refresh(), the router cache update does not
propagate to the RSC table inside the intercepted slot.

On soft navigation (subsequent visits, router cache populated),
the slot state is known and the re-render works correctly.

This is consistent with the behavior described in:

• Issue revalidatePath() not working as expected for Parallel Routes, or for Parallel + Intercepting Routes (modal) #54173 — revalidatePath() not working in Parallel + Intercepted
  Routes
• Issue router.refresh() causes intercepted route to switch to the intercepting route/modal #60844 — router.refresh() causes unexpected behavior inside
  intercepted routes

Both issues were reportedly closed via PRs #59585 and #63263, but the
behavior persists in Next.js 15.4.4 specifically on first hard navigation
in deployed environments.

Expected behavior

After a Server Action completes and revalidateTag is called, the RSC
table inside the modal should re-fetch and display updated data, regardless
of whether it is the first hard navigation or a subsequent soft navigation.

Current workaround

None confirmed. Attempted workarounds:

• revalidatePath with "page" and "layout" scope → does not fix
• revalidateTag → does not fix on first hard navigation
• router.refresh() twice with a delay → inconsistent results
• key prop on Suspense tied to searchParams → skeleton does not
  trigger correctly due to searchParams being cleared before refresh
  completes

Question

Is this a known regression in 15.4.x? Is there a supported pattern for
triggering RSC re-fetches inside Parallel + Intercepted Route modals that
works reliably on both first hard navigation and subsequent soft navigations?

[icyJoseph]

Have you verified this in latest versions? A lot has changed since 15.4 (15.5 is the latest version on the 15 line) ~ Give the latest 16.2 a try, see if this issue persists there, looks like you don't have to do a full production deploy to verify this, just try it locally.

If the issue does persist, I wonder if you could do a quick binary search in the 15.x range. There was a lot of canaries between the latest 14 and 15 - so if something as early as 15.0 still has the issue, then just report back here and I can help further.

[GianBaeza]

Thanks for the suggestion!

I updated from version 15.4 to 16.2 and the issue is no longer occurring. Everything is working correctly now.

Really appreciate the guidance!