You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using createResource after Solid Start 1.0 fails if ssr: true and an exception is thrown in the resource. The error does not come back in myResource.error nor does the resource state transition correctly, and the error boundary is hit instead. This breaks code with no work arounds other than changing all code to return error values instead of exceptions.
This behavior for createResource seems correct. We always throw on read (and always have, the .error property was added later). You can guard the read with the .error property but reading the resource itself directly throws. So if the resource read was in the fallback or vice versa it would not get caught in the ErrorBoundary.
The resource goes into the wrong state regardless and ends up as state ready on the error with the result and error field undefined This is the wrong state. Only happens via SSR=true
I've opened a PR to Solid to add a status === "failure" branch, which makes the repro behave correctly - the resource's status logs "errored" instead of "ready".
Duplicates
Latest version
Current behavior 😯
Using
createResource
after Solid Start 1.0 fails ifssr: true
and an exception is thrown in the resource. The error does not come back inmyResource.error
nor does the resource state transition correctly, and the error boundary is hit instead. This breaks code with no work arounds other than changing all code to return error values instead of exceptions.See note:
https://discord.com/channels/722131463138705510/910635844119982080/1245249872156954708
and stackblitz:
https://stackblitz.com/edit/github-hzq3du-1rmrvf?file=src%2Froutes%2Findex.tsx
Expected behavior 🤔
The exception thrown inside
createResource
shows in the resourceerror
property and not hitting the error boundary.Steps to reproduce 🕹
Steps:
note that the logging and value under error state are incorrect and error boundary is hit instead.
Context 🔦
Normal behavior that worked and is documented but now does not work.
Your environment 🌎
The text was updated successfully, but these errors were encountered: