Route not found anymore

[lukasbash]

Which project does this relate to?

Router

Describe the bug

After an upgrade to 1.136.5 some of my locations cannot be visited anymore and throw an error in the console:

Uncaught (in promise) Error: No route found for location /images
    at getLocation (useBlocker.tsx:182:17)
    at Object.blockerFnComposed [as blockerFn] (useBlocker.tsx:194:20)
    at tryNavigation (index.ts:146:41)
    at Object.push (index.ts:179:7)
    at RouterCore.commitLocation (router.ts:1898:53)
    at RouterCore.buildAndCommitLocation (router.ts:1945:32)
    at RouterCore.navigate (router.ts:1993:17)
    at useNavigate.tsx:35:21
    at onClick (Navbar.tsx:260:17)
    at floating-ui.react.mjs:3166:88

Yet I do not have found the difference to the routes that work, but the patch version before this just works.

Your Example Website or App

See #5888 (comment)

Steps to Reproduce the Bug or Issue

Just navigating to one of those links does not work anymore. I will provide details when I found out more.

EDIT: #5888 (comment)

Expected behavior

Location matching should not break.

Screenshots or Videos

No response

Platform

• Router / Start Version: 1.136.5
• OS: macOS
• Browser: Chrome
• Browser Version: latest
• Bundler: vite
• Bundler Version: 7.2.2

Additional context

No response

[lukasbash]

Ok I think I got the difference. Before this version the order of route children did not matter due to the fact that all routes would be visited during evaluation. It seems the extension of routes matters now in terms of the parent route must come before any route that extends it. In my case

const routeTree = rootRoute.addChildren([
  imageRoutes, // extends index route 
  indexRoute,
  // ...
]);

export const router = createRouter({
  routeTree,
  notFoundMode: "root",
});

If I fix the order it works now. But is this mentioned in the docs? Imagine I define routes dynamically (not file based, but code based) depending on some load order. I guess this is a regression?

[Sheraff]

Could you provide a reproduction? This might highlight an edge-case we would want to add to our test suite to avoid regressions.

[lukasbash]

Could you provide a reproduction? This might highlight an edge-case we would want to add to our test suite to avoid regressions.

Sure thing. There you go! The version 1.136.4 shows the outlet content of the last route:

The route is placed without any dependency order inside the route tree:

const routeTree = rootRoute.addChildren([aboutRoute2, indexRoute, aboutRoute]);

Note that aboutRoute2 is placed before indexRoute even though it refers it as parent.

By simply updating to 1.136.5 the route is broken now:

[Sheraff]

@schiller-manuel Is it valid to declare a parent, but register the child on a different parent?

const aboutRoute2 = createRoute({
  getParentRoute: () => indexRoute,
  path: '/broken',
  component: function BrokenAbout() {
    return </>;
  },
});

const routeTree = rootRoute.addChildren([aboutRoute2, indexRoute]);

To me this sounds like it should be

indexRoute.addChildren([aboutRoute2]);
const routeTree = rootRoute.addChildren([indexRoute]);

because we declared

getParentRoute: () => indexRoute,

But I'm curious if I'm missing something.

---

Registering it as a child of the root route results in this route definition in the routeTree:

{
  "id": "/broken",
  "fullPath": "broken",
  "path": "broken",
  "isRoot": false,
  "options": {}
},

Notice the fullPath doesn't start with a /, which makes the new tree parsing register that segment as "roken".

[lukasbash]

What I might add is that if you fix the order to be in sync with the declaration then everything is working again.
But I always thought the getter of the parent route is stronger (and independent) of the usage in the route tree if provided.

[schiller-manuel]

@Sheraff no that's not valid. also an index route cannot have children

[lukasbash]

@Sheraff no that's not valid. also an index route cannot have children

So you tell me months or years of production ready source code is just wrong without any runtime validation? Are you going to validate this anytime soon? Or what would be your suggestion here?
I understand all of your arguments but just state them wrong without being mentioned anywhere in the docs I do not think its a feasible approach to the developers out there 😕

[Sheraff]

So you tell me months or years of production ready source code is just wrong without any runtime validation? Are you going to validate this anytime soon? Or what would be your suggestion here? I understand all of your arguments but just state them wrong without being mentioned anywhere in the docs I do not think its a feasible approach to the developers out there 😕

Yes, we are looking into adding runtime validation for this type of issue #5897

Sorry for the abrupt close, I figured it wouldn't be too complicated to fix