-
Notifications
You must be signed in to change notification settings - Fork 290
App Router interception resolution is not source-aware when multiple intercepting routes share the same target #730
Description
While working on the targetPattern dedupe change, I noticed what looks like a separate runtime issue in vinext.
With a route structure like this:
app/feed/page.tsx
app/feed/@modal/(..)photo/[id]/page.tsx
app/profile/page.tsx
app/profile/@modal/(..)photo/[id]/page.tsx
app/photo/[id]/page.tsxboth source routes navigate to the same target URL, but they should activate different intercepting routes depending on where the navigation started.
Expected behavior:
navigating from /feed to /photo/123 should render app/feed/@modal/(..)photo/[id]/page.tsx
navigating from /profile to /photo/123 should render app/profile/@modal/(..)photo/[id]/page.tsx
directly loading /photo/123 should render app/photo/[id]/page.tsx
Current vinext behavior:
vinext does not appear to resolve the interception using source-route context
in my testing, it ended up rendering app/photo/[id]/page.tsx instead of the source-specific intercepted route
This seems separate from the route-scanning / validation change around deduping targetPatterns. Even if targetPattern dedupe is fine, runtime interception still needs to distinguish between multiple intercepting routes that share the same target.
My current guess is that interception resolution needs to be source-aware, rather than matching only by the target pathname.
I’m putting together a small demo to compare the behavior between Next.js and vinext and will add more concrete notes once I have that verified.