Bugfix: Incorrect search params stored in cache#94144
Merged
Merged
Conversation
Contributor
Stats cancelledCommit: 84ba3e8 |
Contributor
Tests PassedCommit: 84ba3e8 |
The route cache write was keying entries on `renderedSearch` — the
search string the server actually used to render the page — but
lookups use the requested URL's search component. These two are not
equivalent: for any search-invariant route (e.g. a static page),
`renderedSearch` is `''` regardless of what the request URL carried.
The result was that a request for `/a?foo=bar` against a static page
parked the cache entry at vary path `(/a, '', null)` — the same slot a
clean `/a` lookup keys to. The entry's stored `canonicalUrl` came from
the requesting URL (`/a?foo=bar`), so a later `router.push('/a')` or
`router.replace('/a')` would hit that slot and restore the stale
search string into the browser address bar, `window.location`, and
`useSearchParams()`.
The fix keys cache writes on the request URL's search, not
`renderedSearch`. Entries now sit at the slot keyed by the request
that wrote them, so a lookup for a different search variant doesn't
find them.
Regression test covers the reproduction from the user repo linked in
the bug reports.
Closes #91658
Closes #92187
acdlite
force-pushed
the
acdlite/fix-route-cache-search-params
branch
from
7cea932 to
84ba3e8
Compare
unstubbable
approved these changes
May 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The route cache write was keying entries on
renderedSearch— the search string the server actually used to render the page — but lookups use the requested URL's search component. These two are not equivalent: for any search-invariant route (e.g. a static page),renderedSearchis''regardless of what the request URL carried.The result was that a request for
/a?foo=baragainst a static page parked the cache entry at vary path(/a, '', null)— the same slot a clean/alookup keys to. The entry's storedcanonicalUrlcame from the requesting URL (/a?foo=bar), so a laterrouter.push('/a')orrouter.replace('/a')would hit that slot and restore the stale search string into the browser address bar,window.location, anduseSearchParams().The fix keys cache writes on the request URL's search, not
renderedSearch. Entries now sit at the slot keyed by the request that wrote them, so a lookup for a different search variant doesn't find them.Regression test covers the reproduction from the user repo linked in the bug reports.
Closes #91658
Closes #92187