W
Wasp6mo ago
JakeLoew

useQuery error handling

I'm wondering why useQuery from wasp/client/operations doesn't handle errors as I expect. Consider the following:
// main.wasp
query getApplicationById {
fn: import { getApplicationById } from "@src/server/queries/getApplicationById.ts",
entities: [Application]
}
// main.wasp
query getApplicationById {
fn: import { getApplicationById } from "@src/server/queries/getApplicationById.ts",
entities: [Application]
}
// src/server/queries/getApplicationById.ts
import { Application } from 'wasp/entities';
export const getApplicationById: GetApplicationById<{ id: number }, Application> = async ({ id }, context) => {
throw new HttpError(404, 'Not found');
}
// src/server/queries/getApplicationById.ts
import { Application } from 'wasp/entities';
export const getApplicationById: GetApplicationById<{ id: number }, Application> = async ({ id }, context) => {
throw new HttpError(404, 'Not found');
}
// client/pages/ApplicationPage
function ApplicationPage() {
const { error, isError, status } = useQuery(getApplicationById, {
id: 1,
});

console.log({ isError, status });

return <div>{error?.message}</div>
}
// client/pages/ApplicationPage
function ApplicationPage() {
const { error, isError, status } = useQuery(getApplicationById, {
id: 1,
});

console.log({ isError, status });

return <div>{error?.message}</div>
}
The response from /operations-get-application-by-id is always 404, yet no error is returned from useQuery and isError is always false. status is "loading"
21 Replies
kapa.ai
kapa.ai6mo ago
Hi @JakeLoew. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- The useQuery hook from Wasp is a thin wrapper around the useQuery hook from react-query. It doesn't expect you to supply the cache key and handles it automatically. It accepts three arguments: queryFn, queryFnArgs, and options source (https://wasp-lang.dev/docs/data-model/operations/queries#the-usequery-hook-1). In your case, you're throwing an HttpError with a status code of 404 in your server-side query function. According to Wasp's documentation, if the status code is 4xx, the client will receive a response object with the corresponding message and data fields, and it will rethrow the error (including these fields). However, the server won't forward these fields for any other HTTP status codes source (https://wasp-lang.dev/docs/data-model/operations/queries#error-handling). If you're not seeing the expected error in your client-side code, it could be due to how you're handling the error state with useQuery. The error object should contain the error message you're throwing in your server-side query function. If isError is false and status is "loading", it might indicate that the query is still in the loading state and hasn't received a response yet. If you're still having trouble, it might be helpful to check the version of Wasp you're using and ensure it matches the version of the documentation you're referencing. As one community member pointed out in a Discord thread, it's important to make sure you're looking at the correct version of the docs source (https://discord.com/channels/686873244791210014/1214694033683914762). If the issue persists, it might be worth raising this as an issue in the Wasp GitHub repository or asking for further assistance in the Wasp Discord community. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @JakeLoew, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
JakeLoew
JakeLoewOP6mo ago
I can't seem to figure out what's going wrong. I've filed an issue here https://github.com/wasp-lang/wasp/issues/2208
GitHub
useQuery doesn't handle errors thrown from wasp operation · Issue...
Describe the bug useQuery from wasp/client/operations doesn't seem handle errors thrown from the operation passed to it. Consider the following. The error property returned from useQuery remain...
martinsos
martinsos6mo ago
@JakeLoew You are right, that should work as you expect it to work, which means error is captured on client! Just to check, your Typescript is compiling? I see you don't have a HttpError import in your src/server/queries/getApplicationById.ts but maybe you just ommitted that for brevity? What if you just try returning something else, or throw an error with different code, what kind of behaviour do you get? @sodic pinging you since you were the last doing bigger refactors on the operations side
JakeLoew
JakeLoewOP6mo ago
TypeScript is compiling 👍 the import statement was left out for brevity. Here's the file: https://github.com/JakeLo123/wasp-client-query-error-handling/blob/error-handling/src/tasks/queries.ts If I change the error code thrown, it's reflected in the response observed in the network tab. If I change to 404, it returns 404. The query status remains "loading" and the request is retried over an over while error remains null this repo contains a reproducing example https://github.com/JakeLo123/wasp-client-query-error-handling/tree/error-handling/
martinsos
martinsos6mo ago
I just tried it out on my example, and I can confirm that it works as expected for me! So error 404 gets to the client and I can react to it / print it in my React component. I attached screenshots. You can see in console.logs how react-query tries three times before giving up and then returns an error. I tried this on our examples/thoughts app, here is a link to the commit with changes for this test: https://github.com/wasp-lang/wasp/commit/10d7e77f869147587988af86b0101a8a625590ea .
No description
No description
No description
No description
martinsos
martinsos6mo ago
All right trying out your reproducible example, awesome job on sharing that thanks Ok regarding the reproducible exmaple you shared -> right onw it works (doesn't throw 404, there is no such code). Which changes exactly have you done to get it into problematic state? I want to make sure I am doing exactly the same thing I did this with your example, just added line that throw 404 in the query, and I get good behaviour: after a couple of attempts, react-query gives up and "Error: Error" is printed on screen! Meaning I failed to replicate the issue using your repo. Let me know how it goes with the example I shared if you will be able to run it. If not, maybe you can give me some idea how I can try to get your repro app in the state where I could reproduce the issue. Btw try throwing in a wasp clean just in case.
JakeLoew
JakeLoewOP6mo ago
These are the changes: https://github.com/JakeLo123/wasp-client-query-error-handling/compare/main...error-handling Just removed authRequired from the root page and removed the JSX not relevant to the reproduction. Then updated the getTasks query to throw HttpError hmm. I'm not sure what's different. I just booted up the thoughts app from /examples and it behaved as you described -- 3 attempts and then useQuery returns the error thrown.
martinsos
martinsos6mo ago
Ok I just tried your app from the error-handling branch and it seems to me like it behaves fine, check this screenshot out
No description
martinsos
martinsos6mo ago
So 4 attempts and then it printed an error Try stopping wasp start, run wasp clean, and then run wasp start again, and see if that helps
JakeLoew
JakeLoewOP6mo ago
ahh yes I see it now
No description
martinsos
martinsos6mo ago
it will delete .wasp dir and node_modules dir, to make sure something weird is not happening there from before (I don't see what could cause this, but just tomake sure we have clean slate) Oh ok great it works now! but you weren't getting the "Error: Error ..." printed on the screen before you said? Or you just missed it?
JakeLoew
JakeLoewOP6mo ago
Before it was requesting over and over--much more than 3 or 4 times. Had not seen the error until now. Just did wasp clean and rebooted.
martinsos
martinsos6mo ago
Hm that is weird. That will be up to react-query. You can configre its behaviour regarding stuff like refetching. Aha so you saw this right behaviour only after wasp clean?
JakeLoew
JakeLoewOP6mo ago
Yes.
martinsos
martinsos6mo ago
Ok that is very weird! Might be a coincidence, or maybe not. Did you have this project on wasp 0.13 before and then upgarded it?
JakeLoew
JakeLoewOP6mo ago
Although I was working on another app prior and noticed the behavior there. That's when I decided to try to reproduce with the todo-ts template. I have not run wasp clean in the other app and I think it's still doing the behavior. Let me check.
martinsos
martinsos6mo ago
Ok great give it a look and maybe take a screenshot of logs if you can
JakeLoew
JakeLoewOP6mo ago
Ok it's correct. I must have missed it before 😅 I apologize for that.
No description
JakeLoew
JakeLoewOP6mo ago
It looks like the query attempts again when the window is focused. I think I was missing it when switching windows.
martinsos
martinsos6mo ago
Hmmm! Well the polling behaviour can be confusing if you don't know about it, it is quite unexpected (it was to me in the past). And yes, if you refocus the window it will try again, that is default behaviour (it can be turned off), so that makes it go again into polling and you never get to the final error if you don't wait long enough! Yeah, I think you identified that correctly Ok great! I will close the github issue but In case there is an actual error and it repeats, let us know And thanks for sharing reproducible example that helps a lot
JakeLoew
JakeLoewOP6mo ago
Thank you very much! Yes, reproducible examples are helpful to all!
Want results from more Discord servers?
Add your server