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

[breaking] render raw response when unexpected error occurs in endpoint #6434

Merged
merged 5 commits into from
Aug 31, 2022

Conversation

dummdidumm
Copy link
Member

@dummdidumm dummdidumm commented Aug 30, 2022

..instead of failing completely. Also catch possible fetch error (which would occur when network fails).
Closes #4801
Related to #1931 (maybe even closing it? Can't tell from reading the issue)

There are still some code paths which would bubble up to the handler, but these are of the kind "you use a wrong SvelteKit option" or during prerendering ("cannot use mutative methods .."). The other all look like they have a try-catch around code paths where errors could occur.

Not sure if a test is needed here. We could theoretically do one for the endpoint error.

This is a breaking change insofar as people could have relied on this behavior somehow.

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

..instead of failing completely. Also catch possible fetch error (which would occur when network fails).
Closes #4801

There are still some code paths which would bubble up to the handler, but these are of the kind "you use a wrong SvelteKit option"
@changeset-bot
Copy link

changeset-bot bot commented Aug 30, 2022

🦋 Changeset detected

Latest commit: bf99eac

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

@benmccann
Copy link
Member

I've seen people asking to have their API endpoints return JSON when failing. I'm not sure we necessarily need to address that now, but thought I'd mention it since this seems like it could return HTML errors more often

? json(error_to_pojo(error, options.get_stack), {
status: error instanceof HttpError ? error.status : 500
})
: new Response(error.message, { status: error instanceof HttpError ? error.status : 500 });
Copy link
Member

@Rich-Harris Rich-Harris Aug 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason not to render the HTML error page here? Feels like if the request doesn't specifically ask for JSON we should just do that.

An alternative could be to render the HTML response if sec-fetch-dest is document, otherwise JSON

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhm true we can reuse the static error page here. I didn't know about sec-fetch-dest, I did what was done in a different but related code path where there's also a check to "is this a JSON request".

Comment on lines 318 to 322
try {
return await fetch(request);
} catch (e) {
return new Response(coalesce_to_error(e).message, { status: 500 });
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By try-catching this, we prevent handleError from being called, which seems bad (though honestly I'm not sure how this could fail — fetch only throws if there's a network (including CORS errors) which shouldn't really apply on the server. Is there a reason for this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just being paranoid, looking at all code paths and seing if anything could theoretically fail, and fetch is such a code path. In the related issue it read "handle should never fail" so I thought "ok let's try that then". Maybe it's easier to wrap the whole code into one more big try-catch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I was thinking, yeah

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Differing behavior of exception in shadow endpoint vs ssr
3 participants