`Link` component is buggy when used in app router

[mehulmpt]

Link to the code that reproduces this issue

https://github.com/mehulmpt/nextjs-app-router-link-bug

To Reproduce

1. Clone the GitHub repository
2. Run npm run bugcheck command in your terminal
3. Visit http://localhost:3000

Current vs. Expected behavior

Current behavior:

The links rightly point to /link?productid=1 / /link?productid=2 ... and so on. However, when you click on it, they redirect you to the wrong page!

Expected behavior:

Redirect works properly

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 18.20.4
  npm: 8.19.2
  Yarn: 1.22.19
  pnpm: 8.7.6
Relevant Packages:
  next: 15.1.3 // There is a newer version (15.1.6) available, upgrade recommended! 
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: export

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

Navigation

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

Other (Deployed), Vercel (Deployed), next start (local)

Additional context

I spent 20 minutes debugging this for one of our clients today and finally figured out this is a bug with Next.js itself. The reproduction code above is extremely minimal and does not include anything else other than the required code.

The behavior is very weird, the link shown is correct in the browser preview on the bottom left but the moment it is clicked, it takes you to the wrong page. I am also attaching the video that showcases it:

• In the first half of the video I show you wrong behavior
• In the second half of the video I disable javascript and show you how it should actually work

screenshot-000899.mp4

[PlagueFPS]

I'm having a similar issue with the link component when linking to a new search param value, but my issue is that there is no navigation at all. I can see fetches happening in my network tab but no navigation is happening on the front-end. Refreshing fixes the issue, but only for that pages pagination/search param navigation.

[manuganji]

I have this issue. All the links work once. And then they won't navigate unless I reload the page. I'm on 15.1.6

[manuganji]

I'm seeing this with all relative urls. But I have a vercel/platforms inspired middleware. I'll check if it has to do with any of that code.

[PlagueFPS]

I'm on 15.2.0-canary.28 the latest canary. It's extremely frustrating that for me it only happens in production so it's hard to test workarounds.

[manuganji]

Trying with shallow didn't fix it either.

[icyJoseph]

Do you guys have also a reproduction repository? I think OP's issue is somehow related to export mode, and the express server they use. Haven't had time to deep dive any more.

If query params are missing and such, but only in production, does it also happen on local production builds? And, could we somehow discard other layers on the stack?

[PlagueFPS]

Do you guys have also a reproduction repository? I think OP's issue is somehow related to export mode, and the express server they use. Haven't had time to deep dive any more.

If query params are missing and such, but only in production, does it also happen on local production builds? And, could we somehow discard other layers on the stack?

Don't have a reproduction repo yet, but it does happen in local production builds as well. Just to reiterate the issue in my case:

• Linking a route like /?page=1 via pagination works on first load and on the / page
• Navigating to a new page like /new then linking to a route using pagination like /new?page=1 will NOT work, the navigation will never happen however a fetch for a RSC payload will happen in the background (via the network tab)
• / route's pagination will stay function while /new route's pagination will not.
• Refreshing the page will allow which ever pagination in this case is used first to work functionally while the other will not

[PlagueFPS]

For my case, I have two theories that I am going to try and disprove today on why this may not be a Next.js bug those being, I am using Shadcn's pagination component with next/link, going to test if this is causing issues, and I am also using unstable_cache to cache each page of pagination data, which I will also test.

I'm working on a full minimal reproduction repo to show my findings and hopefully narrow down the issue. However, I only ran into issues once I implemented a new route that also contained pagination.

EDIT: I forgot to mention PPR is also enabled, I've had it enabled for so long that I forget it is still experimental.

[j2ghz]

We're seeing the same issue on what I think is a pretty basic setup, the only experimental feature we have is experimental: { optimizePackageImports: ['lodash-es', 'reactstrap'],}, and on top of that Sentry also enables clientTraceMetadata. We do use output: 'standalone',, but we don't use any middleware, custom server or similar, we just run it in a docker container. For us the issue is present on pages where we use Parallel Routes.

For now we have removed query strings where we could and are waiting for a fix, if another reproduction repo is needed we can have a look at that on Monday.

[PlagueFPS]

Yeah from what I found I could not re-produce the issue using PPR, unstable_cache, or shadcn, so the issue is definitely some underlying issue with either the client-side router cache or next/link components navigation logic. It's inconsistent though, because I cannot reproduce it in a minimal repo at all.

Also this is one of those issues that if widespread it would be causing an uproar as almost every site uses searchParams in some ways. Unfortunately for me, moving away from searchParams is just not possible at the moment so I have to live with this issue. I will be attempting workarounds and I'll report back what (if anything) I find to help.