[GH-ISSUE #730] App Router interception resolution is not source-aware when multiple intercepting routes share the same target #159

New issue

Open

opened 2026-05-06 12:37:44 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:37:44 +02:00

Owner

Originally created by @Debbl on GitHub (Mar 31, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/730

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.tsx

both 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.

Originally created by @Debbl on GitHub (Mar 31, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/730 While working on the `targetPattern` dedupe change, I noticed what looks like a separate runtime issue in vinext. With a route structure like this: ```txt 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.tsx ``` both 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.