Remote function errors don't render +error routes during SSR

[madeleineostoja]

Describe the bug

HTTP errors thrown in remote functions (using the error() helper) are not handled consistently between client rendering and SSR. If a remote function throws an HTTP error during SSR (eg: when called in a +page.server.ts) the appropriate +error.svelte route isn't rendered, triggering the static HTML fallback error page instead.

If you disable SSR, and trigger the same error, the appropriate error boundary/route is used, as if the error occurred in the caller. I believe this is the correct behaviour, or at least I hope it is, because it makes remote functions far more usable.

I originally thought this was intended behaviour and added my voice to this request/issue, but seeing the discrepancy with SSR leads me to believe this is actually a bug.

Worth noting I don't have async Svelte enabled, so I don't think there should be interactions with the SSR limitations that carries.

Reproduction

Code Repro
https://stackblitz.com/edit/sveltejs-kit-template-default-7neh1jev?file=src%2Froutes%2F%2Bpage.js

1. Comment out ssr disabling line
2. Observe issue

Detailed Rerpo

1. Throw an HTTP error in a remote function, using the error() helper
2. Add a +error.svelte boundary to your app
3. Call the remote function in a route
4. Observe the fallback error page getting rendered rather than your error route
5. Disable SSR
6. Trigger the error again, observe the error route getting rendered

Logs

System Info

System:
    OS: macOS 15.5
    CPU: (8) arm64 Apple M1
    Memory: 153.86 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.5.0 - /usr/local/bin/node
    npm: 9.2.0 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 139.0.7258.155
    Firefox: 109.0.1
    Safari: 18.5
  npmPackages:
    svelte: ^5.38.1 => 5.38.1 
    vite: ^7.1.2 => 7.1.2

Severity

blocking an upgrade

Additional Information

This issue is blocking my usage of remote functions in an SSR app, forcing me to either disable SSR (not tenable for this app, SEO matters) or refactor my new remote functions back into dupllicated load function logic

[madeleineostoja]

Has anyone else experienced this? For now I've disabled SSR on our app but it's a pretty big hit and if we can't find a solution we might have to refactor back from remote functions.

[Antonio-Bennett]

@madeleineostoja could you try again with the latest svelte and kit? I know async SSR just landed in kit maybe it fixed the issue?

Edit:
Not landed yet almost though

#14447

[madeleineostoja]

Yep just bumped all my svelte* deps and can still repro the bug, which is what prompted me to bump the thread. I'll try again once async SSR lands (which is exciting in general!)

[Rich-Harris]

The challenge here is that there are two entirely separate error-handling mechanisms. It's not about remote functions per se, but rather about data loading errors vs rendering errors — it's just that in a remote functions world, data loading errors are also rendering errors.

Rendering errors need to be handled with a <svelte:boundary>. Those didn't exist when SvelteKit came out, so +error.svelte was added as a poor man's version of error boundaries, but it only works for load errors. If you have something like {throw_error()} in a component, the root (or built-in fallback) +error.svelte will be shown regardless of where the error occurs.

That's obviously not ideal. It would probably be much better if +error.svelte just created an error boundary for you, and that error boundary was invoked for both load and render errors. Unfortunately we can't just make that change, because it would be breaking — it will have to wait for SvelteKit 3 (which we're all very eager to start working on; there's a lot of legacy code that can be removed when we drop support for Svelte < 5 and Node < whatever).

But you can make it work today, more or less — just add the boundary to your +layout.svelte:

<script>
  import Error from './+error.svelte';

  let { children } = $props();
</script>

<svelte:boundary>
  {@render children()}

  {#snippet failed(error)}
    <Error {error} />
  {/snippet}
</svelte:boundary>

Alas, the 'more or less' is load-bearing — this will work for errors that occur during client rendering, but not during SSR, because error boundaries are no-ops during SSR. That's by design (see sveltejs/svelte#15462 for some background), but perhaps unhelpful in some cases. I don't exactly know what the ideal solution would be here.

[madeleineostoja]

Yeah that 'more or less' caveat is the issue for us. If I'm understanding this correctly (and I may not be, haven't yet played with error boundaries or async svelte), if errors are thrown by remote functions during SSR then there is currently no mechanism to capture and show a custom error state to the user, your only option is to show the bottom level error.html static fallback?

[Rich-Harris]

It doesn't fall back quite that far — if render(...) throws, SvelteKit will attempt to render the root +error.svelte component, and only fall back to error.html if that fails.

Challenges we will need to solve if boundaries are to catch errors during SSR:

• the caller of render(...) still needs to get hold of the error somehow, so that it can be logged and the appropriate status code can be set (imagine your app is constantly showing error UI for some subset of users but your server logs are only showing 200s)
• I said 'get hold of the error somehow' but I should have said errors because you could have an arbitrary number of them. Does that have consequences? What do we do about setting the response status code if, say, one is a 401 and another is a 404?
• in CSR, a <svelte:boundary> is an error boundary if it has a) a failed snippet or b) an onerror handler. Event handlers are ignored in SSR, and it would be weird if boundaries were an exception to that (especially since onerror typically interacts with state). So we'd need to figure out the semantics — is a boundary only an error boundary during SSR if it has a failed snippet?
• any changes we make would ideally be non-breaking

There might be others but those are the ones that spring to mind. IIUC error boundaries don't do anything during SSR in other frameworks (I could be wrong, I haven't checked thoroughly), likely because of these sorts of complexities.

[mihaipoenaru]

My case is that i have a my.app.com/some_id, where some_id may or may not exist, which I believe is a pretty common case

Ideally I'd have something like

<script>
    const data = await fetchData(path.params.some_id) //in my real case, i don't even provide the id here, i just use getRequestEvent inside the remote
</script>

And if the fetchData throws an error(404, 'no data found'), then it should hit an upper boundary in a layout somewhere and render the failed snippet. Adding a root +error.svelte doesn't seem to help either, it still hits the html error file (but I may need to play around with it further, not sure I'm doing it correctly).

Now I have to use the page.server.ts and do the initial load and checks there, and only remote on the client side. Don't get me wrong, this is a superficial ick and I'm aware of it, just that after I started to use remotes it feels so good that I don't even want to look back at the old way of doing things.

[Rich-Harris]

Does the workaround in #14398 (comment) (which will almost certainly be the default in SvelteKit 3) not work?

//in my real case, i don't even provide the id here, i just use getRequestEvent inside the remote

Strongly recommend against this! If page.params.some_id changes, the query will not re-run unless you passed it in as an argument. Depending on how you've set things up that might be fine today but is liable to break in future.

[mihaipoenaru]

Does the workaround in #14398 (comment) (which will almost certainly be the default in SvelteKit 3) not work?

I saw the workaround and i tried something similar. I'm not at my computer right now but IIRC I had a boundary in my root layout (with some placeholder text in the failed snippet), AND a root error file and it didn't work. It's not exactly your example but it should have been close enough imo. But I'll try tomorrow and double check.

Strongly recommend against this! If page.params.some_id changes, the query will not re-run unless you passed it in as an argument. Depending on how you've set things up that might be fine today but is liable to break in future.

Ooof, I forgot about that. In my case there's no way to get from one path id to another, you always have to go back to the main page, so the remote will always run. It should be fine in this case, but it's a really stupid footgun to just leave lying around, thanks for the catch.

[mihaipoenaru]

@Rich-Harris Ok I just checked. It doesn't work 😢

I have a root layout with this:

<script lang="ts">
	import '../app.css';
	import favicon from '$lib/assets/favicon.png';
	import { ModeWatcher, toggleMode, mode } from 'mode-watcher';
	import { SunIcon, MoonIcon } from '@lucide/svelte/icons';
	import { Button } from '$lib/components/ui/button';
	import Error from './+error.svelte';

	let { children } = $props();
</script>

<svelte:head>
	<link rel="icon" href={favicon} />
</svelte:head>

<ModeWatcher />
<svelte:boundary>
	{@render children()}

	{#snippet failed(error)}
		<Error {error} />
	{/snippet}
</svelte:boundary>

<Button onclick={toggleMode} variant="outline" size="icon" class="fixed top-3 right-3">
	{#if mode.current === 'light'}
		<SunIcon class="size-4 scale-100" />
	{:else}
		<MoonIcon class="absolute size-4" />
	{/if}
</Button>

The child page, under the id:

<script lang="ts">
	import State from '$lib/components/State.svelte';
	import { getConferenceForRoom } from '$lib/remotes/conference.remote';

	const conference = await getConferenceForRoom() //this always throws an error(404), for testing purposes
</script>

<some html>

The error.svelte is right next to the layout in the root routes folder. If i go to my.app/some_random_id i get the generic error page instead of mine, where it says:

404 | Error: 404

It would probably work fine for CSR, but if I just type in an id and hit enter in the browser, it's SSR doing its thing, so it crashes to the generic error page, bypassing mine.

I'll be using a duplicated +page.server.ts as a workaround until there's a solution for this, as irksome as that may be.