-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Differing behavior of exception in shadow endpoint vs ssr #4801
Comments
I found a viable workaround. Looks like the |
Is I don't think you're supposed to be trying to catch endpoint errors from Based on a couple of things I see in those logs, I think this may fall somewhere between "rough-edged intended behavior" and "logical result of design choice" -- it looks like one of them is being handled by the router as a navigation (which could be caught with __error.svelte) and the other is being handled by the server "outside" of the router -- but I can't prove it right now, 'cause ya didn't provide a full repro and I don't have time to write yet another full Kit repro. Post a GitHub link to a working repro and I'll take a look at it further. |
Here ya go. I figured a full repo was less easy to understand. 🤷🏻 https://github.com/coryvirok/svelte-exception-bug Relevant changes to the demo app are:
To repro, load the todos page directly (causes SSR to be returned.) Notice the console logs do not contain the If this is a design decision, it definitely needs some documentation since wrapping Lemme know if there's anything else I can provide. Thanks! |
Okay, check this out. I think everything that's going on here is normal behavior. First, I don't think you're meant to catch and deal with errors caused by Second, if you catch the error in Third, I think the strategy SvelteKit wants you to use here is to abstract your database error handling logic out into the I did notice one bug, though, which I'll file a separate issue for... Hopefully some other helpful souls will stop by and provide some other input, but I can't actually find any behavior with this that isn't intended. |
Thanks for putting this together. I set up your repo and verified what you said about not being able to catch the error in Regarding the DB transaction handling - the pattern I'm using is what I've been used to in Flask, Django, Pyramid, and other web app frameworks over the years. Creating a new transaction per request is the safest way to guarantee ACID properties for your routes. Here's a pretty common scenario that requires transaction setup and management in the
In the above scenario, if the transaction logic were pushed into the endpoint, there would be no way to check the auth credentials in the DB based on the auth cookie in 1 place across the entire app. Also, it would lead to tons of boilerplate Or, if 2 transactions were made, (one in TL;DR Is this a pattern that we want to support in SvelteKit? The docs suggest that it is and folks are going to expect that if there's a way to wrap the call to // hooks.js
async function handle(event) {
event.locals.foo = 'some custom data to pass to endpoints, e.g. a DB transaction'
// Handle any exceptions from endpoint and render
try {
// Execute endpoint and render
return await resolve(event)
} catch (err) {
// do something, like rollback the DB transaction
throw err
}
} As always, much appreciation for your time and for this project. The promise of fully server-rendered modern web apps is so, so close! |
Ooh, good catch on the behavior inconsistency with async methods. I wonder where that's getting lost. Now that we've nailed down the case and had some good discussion on the details, I'll probably step back and wait for some maintainer discussion. Hopefully the info we've worked out is enough to make it easy on 'em. 🙂 It seems clear that this is one fuzzy aspect of an error handling framework that has some rough edges overall and needs some thought from an overall design perspective (there's an interesting PR referenced in the issue I filed related to this one), especially around what error handling we should be doing in |
Ooo, thanks for pointing me at that @tcc-sejohnson! More threads to pull on... :) |
Without checking the repros in this thread (just doing some quick triaging for now, will circle back later), I'll just say this: If that's not happening, then it's a bug, but fixing it might be a breaking change for people who are relying on that bug so I've added the appropriate label. |
..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"
…nt (#6434) * [breaking] render raw response when unexpected error occurs in endpoint ..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" * take into account json, call handle error * simplify Co-authored-by: Rich Harris <hello@rich-harris.dev>
Describe the bug
In hooks.js I wrap the
await resolve(event)
in a try/catch in order to do things like rollback a DB transaction.This works fine when the exception is thrown from the shadow endpoint but the exception fails to bubble up to
handle()
when the same page is rendered on the server.Reproduction
Logs
From a full page load (SSR)
From a shadow endpoint fetch (
__data.json
)System Info
Severity
serious, but I can work around it
Additional Information
I'm not 100% sure how to work around it...
The text was updated successfully, but these errors were encountered: