Discrepancy in searchParams between server and client after clicking Link

[kachkaev]

Link to the code that reproduces this issue

https://github.com/kachkaev/next-js-search-params-mismatch-mwe

To Reproduce

1. Clone reproduction repo, run pnpm install and pnpm dev (or pnpm build; pnpm start).

2. Navigate to http://localhost:3000/?a=1&b=3 in a new tab. Observe this page (no issues so far):

   

3. Click on <Link /> components at the bottom of the page, observe changes in displayed values for a and b. All good still.

   Kapture.2024-04-07.at.13.20.33.mp4

4. Navigate to a link that takes you to /, i.e. that unsets both a and b.

Current vs. Expected behavior

Observed state

❌ searchParams in page.tsx is equal to the original value (the one we saw on initial page load).
✅ useSearhParams() returns correct values for a and b.

Expected state

Both sources of searchParams should be in sync (which can be observed after full page reload):

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.11.1
  npm: 10.5.0
  Yarn: 4.0.0
  pnpm: 8.10.5
Relevant Packages:
  next: 14.2.0-canary.61 // Latest available version is detected (14.2.0-canary.61).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A

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

App Router

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

next dev (local), next start (local)

Additional context

If all initial page query params are unset, the bug does not manifest itself. So it’s important to start with something like http://localhost:3000/?a=1&b=3 and not just http://localhost:3000.

---

This bug has implications on pages like e-commerce catalogs which can be filtered. Imagine someone sends you a link to

https://example.com/products?category=shoes&color=red

You’ll see filter controls in the UI and start clicking:
↓
https://example.com/products?category=shoes&color=green
↓
https://example.com/products?category=tshirts&color=green
↓
https://example.com/products?category=tshirts
↓
https://example.com/products?category=tshirts&color=red
↓
...

As long as there is at least one query param in the URL, all works well. But as soon as you navigate to no filters, the catalog will look broken. The URL will be https://example.com/products but the content will be for ?category=shoes&color=red (the initial state of the app router). The only way to see the whole catalog will be to refresh the page.

[kachkaev]

Looks like I have found a workaround. It might be good enough for most people before the issue is fixed in Next.js itself:

kachkaev/next-js-search-params-mismatch-mwe#1

Kapture.2024-04-12.at.23.10.33.mp4

[dmaksimov]

Experiencing this issue as well.

The search params are in sync up until you navigate to the page without any search params.

[samburgers]

Discovered this issue too, and made a clickable minimal reproduction here:
https://nextjs-queryparams.vercel.app/

Source:
https://github.com/samburgers/nextjs-queryparams/blob/main/app/page.tsx

[icyJoseph]

Ahh, we've also hit this one after a major leap from 14.1.x to 14.2.x territory.

Same issue reported here: #65030

@balazsorban44 - sorry for pinging you, but do you think you could drop some thoughts on this issue?

[icyJoseph]

Another update, it might just be a coincidence, but changing staleTime dynamic to zero, seems to do the trick...

• https://nextjs.org/docs/app/api-reference/next-config-js/staleTimes

Perhaps the introduction of staleTimes, causes this issue?

[icyJoseph]

@ztanner Hi, sorry for pinging you on this one, in all honesty I haven't tested this issue in the canaries released this past week, but would you mind investigating what's going on here? Is it expected behavior, or has a bug indeed been introduced?

Next.js 14.3.0-canary.70 still reproduceable

I think the links here, #64170 (comment), are pretty much all you need to see the issue.

[devjiwonchoi]

@kachkaev @icyJoseph Just tested next@14.3.0-canary.73, and it seems to be fixed! Please note that next@canary currently requires the react@canary as well :)

[kachkaev]

This is brilliant, many thanks @devjiwonchoi 👏

[icyJoseph]

Fantastic! Also verified this on a couple of project now. Awaiting a new release now.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.