[breaking] render raw response when unexpected error occurs in endpoint #6434
Conversation
..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 detectedLatest commit: bf99eac The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
|
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 }); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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".
| try { | ||
| return await fetch(request); | ||
| } catch (e) { | ||
| return new Response(coalesce_to_error(e).message, { status: 500 }); | ||
| } |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
That's what I was thinking, yeah
..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:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. All changesets should bepatchuntil SvelteKit 1.0