[PR #822] fix: always mark pages that receive searchParams as dynamic #872

Open
opened 2026-05-06 13:10:35 +02:00 by BreizhHardware · 0 comments

📋 Pull Request Information

Original PR: https://github.com/cloudflare/vinext/pull/822
Author: @southpolesteve
Created: 4/11/2026
Status: 🔄 Open

Base: mainHead: fix/isr-always-mark-dynamic-with-searchparams


📝 Commits (1)

  • 57efd1f fix: always mark pages that receive searchParams as dynamic

📊 Changes

4 files changed (+99 additions, -63 deletions)

View changed files

📝 packages/vinext/src/entries/app-rsc-entry.ts (+9 -9)
📝 tests/__snapshots__/entry-templates.test.ts.snap (+54 -54)
📝 tests/app-router.test.ts (+20 -0)
tests/fixtures/app-basic/app/search-params-page/page.tsx (+16 -0)

📄 Description

Summary

Pages that read searchParams are now always marked dynamic, even when the first request has an empty query string.

Details

Previously, markDynamicUsage() was only called when the URL contained query parameters (hasSearchParams). A request to /page (no query) would render with searchParams = {}, not be marked dynamic, and get ISR-cached. A later request to /page?filter=violet would then receive the cached empty-query response.

The fix removes the hasSearchParams guard so markDynamicUsage() is called unconditionally whenever searchParams is provided to the page component. This matches Next.js behavior where accessing the searchParams prop signals dynamic rendering regardless of whether the URL has query parameters.

Tests

Adds a production integration test with a dedicated fixture page (/search-params-page) that reads searchParams:

  • first request with no query: not cached, renders filter=none
  • second request with ?filter=violet: not cached, renders filter=violet

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/cloudflare/vinext/pull/822 **Author:** [@southpolesteve](https://github.com/southpolesteve) **Created:** 4/11/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/isr-always-mark-dynamic-with-searchparams` --- ### 📝 Commits (1) - [`57efd1f`](https://github.com/cloudflare/vinext/commit/57efd1fe56930e88dda909fd15236cbecb76285a) fix: always mark pages that receive searchParams as dynamic ### 📊 Changes **4 files changed** (+99 additions, -63 deletions) <details> <summary>View changed files</summary> 📝 `packages/vinext/src/entries/app-rsc-entry.ts` (+9 -9) 📝 `tests/__snapshots__/entry-templates.test.ts.snap` (+54 -54) 📝 `tests/app-router.test.ts` (+20 -0) ➕ `tests/fixtures/app-basic/app/search-params-page/page.tsx` (+16 -0) </details> ### 📄 Description ## Summary Pages that read `searchParams` are now always marked dynamic, even when the first request has an empty query string. ## Details Previously, `markDynamicUsage()` was only called when the URL contained query parameters (`hasSearchParams`). A request to `/page` (no query) would render with `searchParams = {}`, not be marked dynamic, and get ISR-cached. A later request to `/page?filter=violet` would then receive the cached empty-query response. The fix removes the `hasSearchParams` guard so `markDynamicUsage()` is called unconditionally whenever `searchParams` is provided to the page component. This matches Next.js behavior where accessing the `searchParams` prop signals dynamic rendering regardless of whether the URL has query parameters. ## Tests Adds a production integration test with a dedicated fixture page (`/search-params-page`) that reads `searchParams`: - first request with no query: not cached, renders `filter=none` - second request with `?filter=violet`: not cached, renders `filter=violet` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vinext#872
No description provided.