Add a default retry handling to avoid retry on specific TRCP errors
I just found that with default settings when using the react client, the query is retried 3 times despite the server sending an UNAUTHORIZED error. I think a default could be to only retry in this cases:
PARSE_ERROR: false BAD_REQUEST: false INTERNAL_SERVER_ERROR: ? UNAUTHORIZED: false FORBIDDEN: false NOT_FOUND: false METHOD_NOT_SUPPORTED: false TIMEOUT: true PRECONDITION_FAILED: false PAYLOAD_TOO_LARGE: false CLIENT_CLOSED_REQUEST: true
I can create a PR if you agree on the general idea
Like this idea, I'm also not sure how to best handle retrying after an INTERNAL_SERVER_ERROR error.
I think I don't want it in the library, but I want the examples to showcase a production-ready version, so it would be good to have some more sensible defaults in here: https://github.com/trpc/trpc/blob/main/examples/next-prisma-starter/src/pages/_app.tsx#L74
Idea:
queries: {
retry(failureCount, _err) {
const err = _err as never as TRPCClientErrorLike<AppRouter>;
const MAX_QUERY_RETRIES = 3;
const code = err?.data?.code;
if (code === 'NOT_FOUND' || code === 'BAD_REQUEST') {
// prevent refetch on queries that always will fail
return false;
}
return failureCount < MAX_QUERY_RETRIES;
},
},
The default behavior of retrying on error is strange to me. Most errors don't resolve automatically. The only error I can think of that should be retried is if the network connection was interrupted.
The current mechanism is problematic for a user since they have to wait for all retries to fail until the app can show the error. This is clearly not desired for errors like 400 Bad request, 401 Unauthorized, 404 Not found. In these cases, we'd rather show the user directly what the problem was so that they can fix it.
Is it possible to completely disable the retry mechanism until something more flexible is put in place?
See the message above, you can customize the behavior fully
Yes it's easy do disable react-query behaviour. For now I ended up using:
new QueryClient({ defaultOptions: { queries: { retry: false } } })
This issue has been locked because it had no new activity for 14 days. If you are running into a similar issue, please create a new issue. Thank you.