Preview:https://svelte-dev-git-preview-svelte-15462-svelte.vercel.app/

⚠️ No Changeset found

Latest commit:87b775b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go.If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Playground

pnpm add https://pkg.pr.new/svelte@15462

I'm still unsure about this strategy, as it won't scale for the case where you don't have afailed snippet, but you do instead use theonerror to update state instead to indicate an error – which is a valid pattern that we've been promoting.

<script>let error=$state();</script><Headererror={error} /><Form>  <svelte:boundaryonerror={e=>error=e}>    <ComponentThatErrors />  </svelte:boundary></Form>

Not to mention this approach will likely break in the future if we ever plan on streaming the SSR HTML payload.

it won't scale for the case where you don't have afailed snippet, but you do instead use theonerror to update state instead to indicate an error

Actually this won't work with SSR, because an error will cause an HTTP 500 and the page will not be rendered at all !

With this PR in case of error the SSR will skip the svelte:boundary children with no replacement since there is nofailed() snippet.
But the page will load, and the client will try to render the boundary children, and eventually run the onerror on client-side...

For streaming, I have never done this, but it may be possible to "pause" the streaming to process this. No ?

Hi,

I made a small example here to show the error with the current version :https://github.com/adiguba/boundary-demo
=> The three page that have error on<svelte:boundary> will show an HTTP 500.

Switch to this PR withpnpm add https://pkg.pr.new/svelte@15462 and all these page will return the content and be functionnal (with some "page shift" due to client-side code)

@adiguba For me, the fact that no other framework seems to render error boundaries on the server and yet don't suffer issues means that maybe we're missing an API on the server that is unrelated to error boundaries?

This feels a little dangerous to me. The fact that we can't invokeonerror handlers during SSR is definitely a problem, but I'm more concerned by the fact that rendering errors would just get swallowed with this approach. For example it's impossible to deploy an update tohttps://svelte.dev that causes the docs to break, because those pages are prerendered; if we had a<svelte:boundary> that swallowed errors caused by type changes or broken links, it would likely take us a while to discover them. Similarly, if I'm monitoring the rate of 500s in my server logs, I'll notice if something is failing to server-render in production, but not if my server is happily renderingfailed snippets instead of the intended markup.

It might not feel totally ideal to 500 the entire page if it would have been possible to serve mostly-functional HTML instead, but I'd definitely prefer it to this, I think.

What's about a way to capture allsvelte:boundary errors during SSR/prerender ?

=>render() could return an array containing the errors that occurred during page generation.
So SvelteKit can still send an HTTP 500, but with a "mostly-functional HTML".