Render `+error.svelte` whenever possible

[theetrain]

Describe the bug

From the docs: https://svelte.dev/docs/kit/routing#error

+error.svelte is not used when an error occurs inside handle or a +server.js request handler.

Not sure if this is a bug or feature request, but I'm thinking +error.svelte should be rendered whenever possible, and not only when performing client-side navigation. The current behaviour is inconsistent (see reproduction below).

Reproduction

https://www.sveltelab.dev/g4cglz64hfgy3vm

1. Load REPL, observe 500 error rendered by error.html
2. Navigate to /test manually in the preview pane
3. Click on 'home' link
4. Observe /src/routes/+error.svelte being rendered instead of error.html

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (4) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @sveltejs/adapter-auto: ^3.0.0 => 3.3.1 
    @sveltejs/kit: ^2.5.27 => 2.20.2 
    @sveltejs/vite-plugin-svelte: ^5.0.0 => 5.0.3 
    svelte: ^5 => 5.25.3 
    vite: ^6.0.0 => 6.2.3

Severity

annoyance

Additional Information

I could not find duplicate issues, and I'm not sure if this is a bug or feature request. If implemented, it would certainly be a breaking change and a potential candidate for SvelteKit 3.

Here's a somewhat related problem presented on Discord: Documentation/help for custom error page for top-level hooks.server.ts error in which someone is attempting to use reroute to maintain the URL while capturing and throwing errors in handle.

[teemingc]

There might have been progress on this already thanks to #16463 . @Nic-Polumeyv do you know what else needs to be done to make +error.svelte return for handle and +server errors if the request expects html?

[Nic-Polumeyv]

Not much, it turned out. respond_with_error already had the guards needed.

[elliott-with-the-longest-name-on-github]

I spent significant time today talking with @Rich-Harris about this and reviewing @Nic-Polumeyv's associated PR and... after all of that, our conclusion is that we don't think it's a good idea to change any behavior here.

Errors that happen in handle are happening either before or after render, but not during. Rich had an example that's pretty contrived, but it illustrates the problem pretty well (and in spite of being contrived, the category of issue is very real):

// src/hooks.server.ts
export async function handle({ event, resolve }) {
  do_some_stuff_that_errors();

  event.locals.dont_give_user_the_nuclear_codes = await user_should_not_have_the_nuclear_codes();
  return resolve(event);
}

// src/routes/+layout.server.ts
import { NUCLEAR_CODES } from '$app/env/private';

export function load(event) {
  return {
    codes: event.locals.dont_give_user_the_nuclear_codes ? undefined : NUCLEAR_CODES
  };
}

The expected behavior of an error that happens prior to resolve is that your route code is never reached. Rendering is a part of the contract; it happens whenever you decide to call resolve(event). Breaking that contract is really weird and can cause you to run into situations where the state of your system is not what you expect it to be -- namely stuff you expect to be set up in handle is just not set up correctly.

It could make slightly more sense for +server.ts files but it's so rare for those to return HTML in the first place that it's really not worth the extra complexity to have them participate in +error pages; we basically have to say "run the endpoint, and if it fails, back out and enter the Svelte rendering pipeline", which is just really weird.

The repro provided here does exhibit inconsistent behavior, but the reason pretty much makes sense: We're already in a context that can render Svelte, and we definitely already ran handle correctly, because we were able to render for the first time. The "correct" thing to do here would actually be to reload so that error.html renders instead of the +error.svelte page, but honestly that adds more complexity for not much benefit.

[Nic-Polumeyv]

Extremely thankful for the feedback, I should have considered all of those effects.