AI & Agent Dev Bug Sandbox logo
AI & Agent Dev Bug Sandbox
Back to Radar

Refresh Under Intercepted Modal Triggers MPA Fallback When Background Page Is Interceptable

When a modal is opened via interception over a page that is itself interceptable, performing a router.refresh() or revalidatePath causes the background route refresh request to incorrectly include the Next-Url header, leading to an intercepted response and an MPA fallback, resulting in a full page load and loss of client state.

highConfidence 95%Next.jsAffected V16.3.5Affected V16.3.8Affected V16.4.0-Canary.59

Origin Analysis

The refresh logic for reused background routes sends the current Next-Url header (from the primary refresh request) instead of the Next-Url that was used when the route was originally fetched. For document-loaded pages (no interception), this should be omitted, but the code incorrectly includes it, causing the server to apply interception rewrites and return an intercepted tree, which mismatches the expected page tree and triggers a hard navigation.
1. Run the reproduction app. 2. Open /photo directly (document load). 3. Click 'Settings' nav link; the intercepted modal opens. 4. Click 'router.refresh()' or trigger a Server Action with revalidatePath. Observe that the page reloads as /settings (MPA fallback) instead of refreshing in place. Compare with /plain (non-interceptable) where refresh works as expected.

Fixing Code Block

Edge Case Audit

This hotfix may not cover all cases where the Next-Url should be different but not undefined (e.g., nested interceptions). It could also break scenarios where a background route was originally intercepted but is refreshed while a different URL is active. A more robust fix would track the Next-Url per route segment in the router state. Rollback: revert to the previous code; the bug will reappear but no new issues introduced. Test thoroughly with parallel routes and nested interceptions.

Ecosystem Topology