next/navigation router.push does not fully navigate

[alja-dips]

Link to the code that reproduces this issue

https://github.com/alja-dips/next-bug (Note: This code does not manage to reproduce the issue, but is as close as I get making a minimal example of what our codebase does)

To Reproduce

1. Run form submission
2. Form submission calls server actions with data
3. Server actions use revalidatePath on certain pages to ensure that user navigation to these pages will have fresh data
4. Upon successful server action calls call router.push
5. Observe RSC calls in network tab
6. Nothing happens

Current vs. Expected behavior

Current: User is not redirected to desired page upon call to router.push
Expected: User is redirected to desired page upon call to router.push

Provide environment information

Operating System:
  Platform: linux (WSL/Docker)
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025
  Available memory (MB): 15826
  Available CPU cores: 20
Binaries:
  Node: 22.18.0
  npm: 11.5.2
  Yarn: N/A
  pnpm: 10.15.0
Relevant Packages:
  next: 15.5.1-canary.24 // Latest available version is detected (15.5.1-canary.24).
  eslint-config-next: 15.5.0
  react: 19.1.1
  react-dom: 19.1.1
  typescript: 5.9.2
Next.js Config:
  output: standalone

Which area(s) are affected? (Select all that apply)

Not sure, Linking and Navigating

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

Additional context

The issue is not reproducible consequently and hence is suspected to be some kind of race condition or intermittent error. I have attempted to create a minimal repo with a setup similar to what we are doing in our corporate project, but this project setup does not manage to reproduce the issue. Because the codebase in which this issue happens is proprietary I am not free to share the code, but will happily share what information I am allowed to in the hopes of tracking down and resolving the issue.

The issue has been seen both in dev, start, and the production docker build.

In our playwright test traces we can see that each attempt to call router.push results in an RSC call to the target path. Each RSC call responds with 200 OK. This RSC call looks something like this:

--- REQUEST ---
Method: GET
Status Code: 200 OK
Request Headers
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US
Connection: keep-alive
Cookie: {AUTH COOKIE REMOVED}
Host: localhost:3000
Referer: {REMOVED}
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.7339.16 Safari/537.36
next-router-state-tree: {REMOVED}
next-url: {TARGET URL}
rsc: 1
sec-ch-ua: "Chromium";v="140", "Not=A?Brand";v="24", "HeadlessChrome";v="140"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

---RESPONSE---
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/x-component
Date: Wed, 03 Sep 2025 12:02:32 GMT
Keep-Alive: timeout=5
Transfer-Encoding: chunked
Vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding

Unfortunately playwrights traces does not keep the RSC response bodies so we are unable to inspect their contents.

We've attempted to strengthen the push function with retry logic using the code below, but this only results in more rsc calls but no effect.

export function useNewRouter() {
  const router = useRouter();

  return {
    ...router,
    push: (path: string) => {
      const initialurl = window.location.href;

      router.push(path);

      let attempts = 1;
      const interval = setInterval(() => {
        if (window.location.href === initialurl && attempts <= 3) {
          Log.debug(
            `Initial router push failed to change url to "${path}". Trying again.`,
          );
          router.push(path);
          attempts++;
        } else {
          clearInterval(interval);
        }
      }, 2500);
    },
  };
}

The issue has persisted for about a year, so it has been a problem with-/our usage of- next for some time. We've attempted to migrate the code to use a server side redirect(...) call instead and observe similar behavior as it appears these server side redirect calls use the client side router to perform these redirects after the fact, but this I am less sure about.

[icyJoseph]

Do you use any client side error reporting? polyfills? global navigation listeners?

[alja-dips]

Not as far as I know. We use opentelemetry's automatic instrumentation in production, but this is turned off locally and in test where we've also observed this bug so it should not be due to this.

[DarkSmile92]

Having the same issue ever since the upgrade to v15 (pages router)

[truefalse10]

I am experiencing the same issue with next/link on a server-rendered page. I can see the XHR request is being returned successfully but the navigation does not happen. If I click a couple of times the navigation sometimes does work though. This only happens in production mode, not on the dev server. Next v15.5.3

[mikaelahlinder]

I am experiencing the same issue with next/link on a server-rendered page. I can see the XHR request is being returned successfully but the navigation does not happen. If I click a couple of times the navigation sometimes does work though. This only happens in production mode, not on the dev server. Next v15.5.3

+1

[icyJoseph]

Please, adding +1 is not moving this forward. We have a reproduction repository that doesn't trigger the issue and reports pointing to App and Pages Router. Is there anymore context we can contribute? Libraries used? can it be triggered in a create-next-app with no additional packages?

[alja-dips]

I've managed to reproduce what I think is the issue in our case. It's a combination of a performance issue and a possible misconfiguration of the loading.(tsx|jsx) files, or a missing Suspense boundary. I have updated the reproduction repository with a minimal example that reproduces our "issue", and I've written a Playwright test to verify it.

Looking at the behavior in the network tab, it appears to match exactly what we see in our production and test environments with the real code. We observe an RSC call that completes, and then nothing happens. This is what initially misled me to think it was a router bug since there was no indication of a state change occurring in the network tab.

I can't pinpoint exactly why our production code behaves this way, especially since we've been diligent about using loading.tsx files and Suspense boundaries. However, based on the identical behavior between the reproduction repo and our production code, this explanation seems to be the most reasonable one.

For the reproduction repo, I've implemented a simple fix in the fix-issue branch by adding a loading.tsx file to the root of the app directory. This change causes the navigation to happen almost instantly as the loading.tsx file is substituted in for the very slow layout, allowing the url to change immediately.

I can't speak on behalf of the other folks in this thread as to whether this would resolve their issues. I suspect that my original bug report probably isn't an issue in NextJS, but rather a configuration problem in our application. I recommend that other contributors who've experienced similar symptoms try to determine if they're encountering the same issue I've described, or different ones that warrant separate bug reports.

I myself won't immediately close this issue to leave the discussion open.

@icyJoseph feel free to consider this issue resolved on my part, and close the issue if you see this as the correct action in regards to the discussion. I'll open a separate issue if I discover a problem in the way the loading.tsx files or suspense boundaries work. Though most likely it's just user error.

[truefalse10]

For me it seems to be an issue with nextjs. Changing the nextjs version from 15.5.3 to 15.6.0-canary.2 completely solved the problem. @alja-dips I already have a root loading.tsx in place but on the stable version the problem remains.

[icyJoseph]

@truefalse10 is it possible for you to try to identify the first canary where it gets fixed?

The canary list is a bit odd... but you likely wanna try v15.5.1-canary.x kind of, for example v15.5.1.-canary.39, etc, ignore that 15.5.3 looks like a higher version.

• https://github.com/vercel/next.js/tags here are more canary tags you can try

First try with 15.6.0-canary.1 and 15.6.0-canary.0, otherwise do a binary search between v15.5.1.-canary.39 and v15.5.1.-canary.0 - (15.5.3, and 15.5.2 are only back porting fixes)

[truefalse10]

I am not sure if I can follow the canary logic. What I have tried so far:
✅ v15.6.0-canary.0 has the fix
✅ v15.5.1-canary.39
❌v15.5.1-canary.0 shows the bug

Do you want me to try all the versions in between 15.5.1 canary.0-39?

Edit: I tried many canary versions and I am pretty confident that the bug got fixed in v15.5.1-canary.26 Its the first version where next/links work as expected.

[icyJoseph]

Greatly appreciate it. Sorry that the canary numbering got a bit weird. We also got internal feedback about this... so i https://github.com/vercel/next.js/releases/tag/v15.5.1-canary.26 fixed it... so it has to be an upstream fix in React 🤔

[miami-man]

when you say it has to be an upstream fix in React, is there an open issue about this in React repo you can share link to? Was not able to find this in their issues...

[icyJoseph]

Nah, in this case, IIRC, it was that @truefalse10 listed this canary, https://github.com/vercel/next.js/releases/tag/v15.5.1-canary.26 as where the next/link works as expected

If you see the commits on that canary, it is two docs changes and a React version update in Next.js