Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix Updating search params on the page that is interceptable causes the intercepted route to render [1 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#86362•Fetched 2026-04-08 02:11:27
View on GitHub
Comments
2
Participants
2
Timeline
8
Reactions
3
Author
devinatbrytdevinatbryt
Participants
devinatbrytdevinatbrytrosbitskyyrosbitskyy
Timeline (top)
commented ×2labeled ×2referenced ×2cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #12: Prevent route interception when only search params are updated

Description (problem / solution / changelog)

What?

This fix prevents interception routes from being triggered when updating search parameters on the same page. A check was added to compare pathnames before passing nextUrl, passing null instead if only search parameters have changed.

Why?

Previously, route interception would incorrectly occur even when only the search parameters on the page were updated. This behavior caused unexpected navigation issues.

How?

  • Modified navigateReducer to check if pathname has changed before passing nextUrl.
  • Pass null instead of state.nextUrl when the pathname remains unchanged.
  • Added a test case to ensure the proper behavior of this fix.

Closes NEXT- Fixes #86362

-->

Changed files

  • packages/next/src/client/components/router-reducer/reducers/navigate-reducer.ts (modified, +6/-1)
  • test/e2e/app-dir/interception-search-params-update/app/@modal/(.)search/page.tsx (added, +13/-0)
  • test/e2e/app-dir/interception-search-params-update/app/@modal/default.tsx (added, +3/-0)
  • test/e2e/app-dir/interception-search-params-update/app/@modal/layout.tsx (added, +9/-0)
  • test/e2e/app-dir/interception-search-params-update/app/layout.tsx (added, +13/-0)
  • test/e2e/app-dir/interception-search-params-update/app/page.tsx (added, +11/-0)
  • test/e2e/app-dir/interception-search-params-update/app/search/page.tsx (added, +55/-0)
  • test/e2e/app-dir/interception-search-params-update/interception-search-params-update.test.ts (added, +77/-0)
  • test/e2e/app-dir/interception-search-params-update/next.config.js (added, +6/-0)

Code Example

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025
  Available memory (MB): 15954
  Available CPU cores: 12
Binaries:
  Node: 22.20.0
  npm: 10.9.3
  Yarn: 1.22.22
  pnpm: 10.13.1
Relevant Packages:
  next: 16.0.3 // Latest available version is detected (16.0.3).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: N/A
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/devinatbryt/route-interception-bugs

To Reproduce

  1. Run pnpm i.
  2. Visit /search route.
  3. Route will be intercepted.
  4. Hard reload page, this will show the normal page.
  5. Type in search field which causes search params to be updated.
  6. Two search fields appear since intercepted route appears due to using router.replace method.

Ignore the bug that occurs once you start typing in the intercepted route's field after the intercepted route appears.

Current vs. Expected behavior

I would expect the following:

  1. If you're not already on the intercepted route, then when attempting to client side navigate, the intercepted route should do it's job.
  2. However, if you're already on the route the interceptor is meant to intercept, the route interceptor should not be able to intercept the route. Especially if the search params of that route are changing.

The above is how it should work, that being said, there also should be a way to control bypassing an intercepted route in both the Link component and "router.push/router.replace" methods.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025
  Available memory (MB): 15954
  Available CPU cores: 12
Binaries:
  Node: 22.20.0
  npm: 10.9.3
  Yarn: 1.22.22
  pnpm: 10.13.1
Relevant Packages:
  next: 16.0.3 // Latest available version is detected (16.0.3).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

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

Linking and Navigating, Parallel & Intercepting Routes

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

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

Additional context

I have only ever used intercepted/parallel routes in Nextjs 16, so I have no idea if the above is an issue within previous versions. That being said, I was surprised that there aren't existing methods to allow someone to bypass route interception when using router.replace/push and the Link component.

I appreciate you guys looking into this!

extent analysis

TL;DR

The issue can be addressed by implementing a conditional check to prevent route interception when the user is already on the intercepted route and the search parameters are changing.

Guidance

  • Review the router.replace method implementation to ensure it correctly handles route interception when the user is already on the intercepted route.
  • Consider adding a conditional check to prevent route interception when the search parameters are changing, as expected in the current vs. expected behavior section.
  • Investigate the possibility of introducing a bypass mechanism for route interception in the Link component and router.push/router.replace methods.
  • Verify the issue is specific to Next.js 16 by testing with previous versions, if possible.

Example

No code snippet is provided due to the lack of specific implementation details in the issue.

Notes

The issue seems to be related to the implementation of route interception in Next.js 16, and the expected behavior is clearly described. However, without more information about the custom implementation of the router.replace method and the route interception logic, it's challenging to provide a more detailed solution.

Recommendation

Apply workaround: Implement a conditional check to prevent route interception when the user is already on the intercepted route and the search parameters are changing, as this seems to be the most straightforward way to address the issue without modifying the underlying Next.js implementation.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#embedding generation#cache error#pipeline error#runtime error#dependency conflict

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING