Blank screen/out of memory with root loader and hash history

[BrendanC23]

Describe the bug

I'm trying to use a root route with a loader and hash history (which is needed for Electron, though this issue also occurs on the web). I have the following:

// __root.tsx
export const Route = createRootRoute({
  loader: () => {
    return { data: 'data' };
  },
  component: RootComponent,
});

// main.tsx
const history = createHashHistory();

// Set up a Router instance
const router = createRouter({
  routeTree,
  history,
  defaultPreload: 'intent',
});

When both of these are used, the page fails to load. This doesn't always occur when viewing a StackBlitz preview as part of the editor, but will occur if you open the preview in a new tab. The page loads forever and does not show anything. Dev tools are also empty.

Eventually, there is an out of memory error.

If the loader is removed or the history is removed from the above code, the page loads normally.

Your Example Website or App

https://stackblitz.com/edit/tanstack-router-veongn?file=src%2Froutes%2F__root.tsx

Steps to Reproduce the Bug or Issue

1. Open the StackBlitz reproduction and open the preview in a separate browser window
2. The page loads forever and nothing is rendered
3. Comment out the history, in line 12 in main.tsx. Notice that the page loads properly. Uncomment the line.
4. Comment out the loader in lines 6 - 8 of __root.tsx. Notice that the page no longer loads.

Expected behavior

I expected that the page will load fine even when the root route has a loader and hash history is used.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: StackBlitz running in Chrome or FireFox
• Occurs using electron@31.0.2
• @tanstack/react-router@1.45.4
• @tanstack/router-devtools@1.45.4
• @tanstack/router-plugin@1.45.3

Additional context

No response

[schiller-manuel]

looks like this was introduced in 1.45.3

@tannerlinsley can you please have a look?

it works in 1.45.2: https://stackblitz.com/edit/tanstack-router-yaeuoc?file=package.json

[schiller-manuel]

@BrendanC23 as a workaround, you can use createMemoryHistory instead of hash history

[geoff-harper]

I think it's broader than that. I'm getting oom by simply returning the zod result in validateSearch of my index root. If I don't return anything it's fine. This is just with the stock router

[schiller-manuel]

@geoff-harper can you please provide a reproducer?

[geoff-harper]

I'm pretty swamped at the moment. I may be able to get to it next week if it isn't found by then. It's a basic router with a query client in context. Here's the entire tree I have after removing everything I could

declare module '@tanstack/react-router' {
  interface FileRoutesByPath {
    '/_page/': {
      id: '/_page/';
      path: '/';
      fullPath: '/';
      preLoaderRoute: typeof PageIndexImport;
      parentRoute: typeof rootRoute;
    };
  }
}

My __root is nothing but an Outlet. _page has an Outlet and plain text pending and error components. _page.index is just an Outlet with a validate search of

validateSearch(search) {
    const cached = sessionStorage.getItem(storageKey) || '';
    const parsed = defaultParseSearch(cached);
    const validated = schema.parse(parsed);

    return validated;
  }

Here's the router

export const router = createRouter({
  routeTree,

  defaultPreload: false,
  defaultPreloadStaleTime: 0,

  context: {queryClient},
});

It's as stripped down as I can make it. If this isn't enough to go off of I can try and do a full repro when I'm available

[ruiaraujo012]

I'm having the same issue that @geoff-harper has but with file based route and createRootRouteWithContext when using valibot validate search, but in a strange scenario, when I navigate to the route it works, if I press F5 it crashes. If I paste the URL manually it crashes too, it started happening after upgrading from v1.45.2 to v1.45.3 and above

const SearchSchema = v.object({
  'max-date': v.fallback(v.union([v.string(), v.null()]), null),
  'min-date': v.fallback(v.union([v.string(), v.null()]), null),
  page: v.fallback(v.number(), DEFAULT_TABLE_PAGE),
  size: v.fallback(v.number(), DEFAULT_ROWS_PER_PAGE),
});

export const Route = createFileRoute('/_private/private/supplies/')({
  component: () => <ListSuppliesPage />,
  validateSearch: (search): Required<GetSuppliesParams> => v.parse(SearchSchema, search),
});

The strangest thing is that if I run pnpm build the issue disappears, seams to be something in dev mode only.

[ruiaraujo012]

@geoff-harper Are you using Router Devtools? If so, can you try again without? I found that it was the cause of my issues.

[itshallrun]

I can confirm that there is somewhere a bug with the HashHistory which leads to an infinite loop and tab freeze I can`t reproduce it in an isolated environment yet and can't post my whole codebase here. But I could narrow it down slightly. This may help.

Tested in Chrome and Firefox. The error causes the Browser tab to freeze, which usually happens with an infinite loop. It occurs only when accessing the root URL directly without the /#/ e.g. localhost:5000 will freeze localhost:5000/#/ works fine

I can also confirm, that you can work around that issue by either using the Memory or BrwoserHistory or by downgrading the version to 1.45.2 or below.

So it must have been introduced in 1.45.3

The dev tools or absence of those do not affect it for me

[geoff-harper]

I checked out 1.45.11 and it's tentatively working. I'm not using HashHistory so I suppose my issue was different and potentially resolved along the way. If it pops up again I'll open a new issue with repro (and try w/o dev tools)

[devarsh]

I can also confirm, that this issue exist in version 1.45.3 onwards for hashRouter and its exactly the same as mentioned by @itshallrun

[itshallrun]

@devarsh do you have a reproduction? Your project may be smaller than mine.

[Rosadojonathan]

I don't have a repo to show reproducibility as I'm using it in production, but I'm still having the issue. Our smoke tests are still failing with version v1.45.15 so we are sticking to v1.45.2 until we get a green build

[Rosadojonathan]

Seems like v1.46.4 (or more recent, didn't test before) fixed this issue. Thanks!

[SeanCassiere]

Closing since retesting with 1.52.0 no longer shows this bug.