This is a braindump follow-up to #4665, which addresses #4815. As of #4665, the behaviour seen in #4815 will be different — it will render the plaintext error page (because an error status is returned from __layout during the rendering of the __error page), which isn't what we want.

One possible solution to that is to expose status and error to __layout components, so that if a layout does something like this...

if (!$session.user) {
  return { status: 401 }
}

...it's possible to skip that when load is called a second time during rendering of the generic error page:

-if (!session.user) {
+if (!session.user && status === null) {
  return { status: 401 };
}

This does feel rather messy, and does feel like it hints at a deeper design flaw. It also adds some complexity, since ordinarily layouts don't see these values (we only 'unwind' layout/leaf nodes until we hit an __error that we can render; we don't re-run __layout and so there's no opportunity to present status/error), there's a distinction between generic and non-generic error pages, which has to be somehow replicated in the client (at present it's easy, because if we initialise the client with an error, only the specified __error page gets to see it).

An alternative, as suggested in #4815 (comment), is for __error pages to be completely separate from the layout tree. I don't love that, since aside from being a significant breaking change it would mean a lot of code duplication between __error and __layout.

Needs some further thought. In the meantime, I'm just going to leave this here.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0