Error page still loaded when redirecting

[LorenzoLeonardini]

Describe the bug

This is the scenario: I have a conditional redirect in __layout.svelte which checks if the current path starts with a certain prefix. Let's say "foo". If I go to /foo/bar and routes/foo/bar.svelte exists, I correctly get redirected and the bar page does not get loaded. If I go to /foo/baz and that page does not exist, the __error.svelte page still gets ssr-ed and loaded and sent to the browser.

In my specific project, this becomes a problem because with /foo/baz the error page fails to load because it tries to access unavailable stuff, the server returns an error 500, which overrides my 302 redirect and the user gets stuck on an error page. This wasn't happening in Sapper (I migrated yesterday), so I don't know if it's a bug or a design change.

Reproduction

To reproduce I set up a very simple repo: https://github.com/LorenzoLeonardini/sveltekit-redirect-reproduction
Just visit /foo[whatever] and in the console you get proof the error page gets loaded:

Error: Not found: /fooasd
    at resolve (file:///tmp/my-app/node_modules/@sveltejs/kit/dist/ssr.js:1754:13)
    at async respond (file:///tmp/my-app/node_modules/@sveltejs/kit/dist/ssr.js:1696:10)
    at async svelteKitMiddleware (file:///tmp/my-app/node_modules/@sveltejs/kit/dist/chunks/index.js:4558:22)

If the browser is slow enough you can also see the error page before you get redirected: https://i.imgur.com/5exhl6C.gif

Logs

No response

System Info

System:
    OS: Linux 5.15 Arch Linux
    CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
    Memory: 635.48 MB / 11.57 GB
    Container: Yes
    Shell: 5.1.12 - /bin/bash
  Binaries:
    Node: 17.1.0 - /usr/bin/node
    Yarn: 1.22.17 - /usr/bin/yarn
    npm: 8.1.3 - /usr/bin/npm
  Browsers:
    Firefox: 95.0
  npmPackages:
    svelte: ^3.44.0 => 3.44.3

Severity

annoyance

[dummdidumm]

The problem is that the route is matched using the manifest with all possible routes, and matching is done using a regex containing the whole route url. In this case, no route matches, so nothing (no layouts or page) is loaded and instead the root 404 case kicks in. The GIF behavior happens because the root layout contains the redirect logic, and the root layout is always loaded, so the redirect happens on hydration.

For this case to be supported we would need to adjust the route matching logic to instead check each part of the url (for foo/bar, check foo, then bar), use the longest match and run the nodes until you hit a redirect or then backtrack to render the neareset error page.

[LorenzoLeonardini]

I think the route matching is fine, and redirecting is the intended behaviour.

What I would expect, though, would be the redirect in the load function to short circuit the current page load and load the new one. Don't know if that's the right thing to do in a general case, though.

[LorenzoLeonardini]

I don't recall the exact problem I was dealing with when I opened the issue, this is my current interpretation. Phrasing wasn't great

[dummdidumm]

Possibly related: #1575

[Rich-Harris]

Going to close this as it's intended behaviour. You'd need to have a foo/[...rest] route for the root layout to load outside of the not-found-error-page scenario