Skip to content

App Router interception resolution is not source-aware when multiple intercepting routes share the same target #730

@Debbl

Description

@Debbl

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions