Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: correctly handle HttpError on the client #8829

Merged
merged 4 commits into from
Feb 3, 2023

Conversation

gtm-nayan
Copy link
Contributor

@gtm-nayan gtm-nayan commented Feb 1, 2023

Closes #7966
Closes #8142

Reading this comment, there's a chance I may have completely misunderstood what the PR was trying to do, but at least this is what I got from the repro and the list of steps on #7966.

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. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

@changeset-bot
Copy link

changeset-bot bot commented Feb 1, 2023

🦋 Changeset detected

Latest commit: f8ca097

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@sveltejs/kit Patch

Not sure what this means? Click here to learn what changesets are.

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

@dummdidumm
Copy link
Member

The problem I tried to articulate there is that if you throw an error from the handle hook, there's nothing to fall back to. The handle hook is "above" the root layout, which means we need to fall back to the static error page (which you can customize through error.html). That happens when hitting the server directly already, but for the client there's no good way to do that currently: If the error is thrown from a __data.json request, we can't magically transform that response into the static error page. We can't just show the root layout and its error page either, because the root layout might fire off another __data.json request, which results in another error thrown in the handle hook.

@gtm-nayan
Copy link
Contributor Author

Trying to wrap my head around it, but feels like that probably warrants a separate discussion, this change still addresses #7966 right?

@dummdidumm
Copy link
Member

Sort of - if you have a +layout.server.js in your root, that request will still be done when falling back to the root error page with the root layout, which triggers another handle hook invocation. This will probably trigger a full reload and that will show the static error page, but if you're in SPA mode then it won't I think.

This PR makes sense to me in either way because the unexpected error which is thrown while request __data.json should've been handled by the server and its handleError already, so it shouldn't result in another client handleError invocation.

@gtm-nayan gtm-nayan marked this pull request as ready for review February 2, 2023 08:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

support for throwing error in handle function
2 participants