-
I suggest exposing the error that led to retrying the query as We are using react-query to drive an unattended dashboard implementation where the underlying data can become available at a later point in time. Because there is no user input available we need to retry infinitely, but we want to disable the current state of retry why it failed, e.g not found or some schema validations errors. Therefore we configured the {
retry: true, // Retry forever
retryDelay: 5000,
}; We can track if the query is still retrying by const useConfig = (configId: string) => {
const [retryError, setRetryError] = useState(null);
const { data } = useQuery(
["config", configId],
async () => {
try {
const response = await fetch(`/static/${configId}.json`);
if (!response.ok) {
throw new ConfigNotFoundError(configId);
}
const json = await response.json();
const config = configSchema.parse(json);
setRetryError(null);
return config;
} catch (error) {
setRetryError(error);
throw error;
}
},
{ retry: true, retryDelay: 5000 }
);
return { data, retryError };
}; This works if the query is used only in a single place, but fails if it used in multiple places since the error only is set on the hook actually executing the query function. So we evolved the solution to use a second query key for error storage: const useConfig = (configId: string) => {
const queryClient = useQueryClient();
const queryKey = ["config", configId] as const;
const errorQueryKey = [...queryKey, "error"] as const;
const { data } = useQuery(
queryKey,
async () => {
try {
const response = await fetch(`/static/${configId}.json`);
if (!response.ok) {
throw new ConfigNotFoundError(configId);
}
const json = await response.json();
const config = configSchema.parse(json);
queryClient.setQueryData(errorQueryKey, null);
return config;
} catch (error) {
queryClient.setQueryData(errorQueryKey, error);
throw error;
}
},
{ retry: true, retryDelay: 5000 }
);
const { data: retryError } = useQuery(errorQueryKey, () => null);
return { data, retryError };
}; We could drop this code completely if we could access the error that triggered the retry. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Yeah I think this would be possible. We have a |
Beta Was this translation helpful? Give feedback.
Yeah I think this would be possible. We have a
fail
action internally that has access to the "current error", but right now, it only increments thefailureCount
. Not sure about the naming though, maybefailureReason
would be better? Suggestions and PRs welcome :)