-
Notifications
You must be signed in to change notification settings - Fork 1.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
Retry on error with suspense #1907
Comments
@Babailan sorry for the delay. I was on vacation as you replied and missed to answer. I don't understand what you mean. I am aware of the usefulness of the retry feature. My report is, that it seems not to work when enabling |
@micha149 I think you didn't provide the Suspense Component. and i thought your problem is 2 request has been made everytime you are requesting. suspense: https://17.reactjs.org/docs/concurrent-mode-suspense.html |
@Babailan I would like to say that I know what I am doing. Concepts like suspense are familiar to me. I created a codesandbox to demonstrate my issue. In this box a fake fetcher will fail for the first request, for a retry it returns some data so the greeting message can be displayed. Set the variable https://codesandbox.io/s/swr-suspesnse-retry-bug-sqpjyn?file=/src/App.js |
Is there any progress on this issue? I'm having same problem. |
I've encountered this also. I can see why not refetching on render makes sense for non-suspense usage (errors in non-suspense don't suspend rendering). For suspense, I think this is unnecessary - a thrown error will suspend rendering. When the error guard retries rendering the failed path, IMHO, it should try the request again (I think this is what is done in urql). Is there openness to a PR to add this functionality? Edit: Tried to nuke the cache as a temporary workaround but that isn't possible due to the context not being exported. |
I got around this issue by writing a middleware which calls my custom const retrySuspenseSWRMiddleware: Middleware = (useSWRNext: SWRHook) => {
return (key, fetcher, options) => {
if (options.suspense) {
const suspenseFetcher: typeof fetcher = async (fetcherOptions) =>
new Promise(async (resolve, reject) => {
let retryCount = 0;
async function retry() {
try {
const data = await fetcher(fetcherOptions);
resolve(data);
return data;
} catch (error) {
retryCount += 1;
onErrorRetry(error, retryCount, retry);
}
}
try {
await retry();
} catch (error) {
reject(error);
}
});
return useSWRNext(key, suspenseFetcher, options);
}
return useSWRNext(key, fetcher, options);
};
}; Then I passed it in my The Lines 16 to 38 in e81d22f
EDIT: Turns out you can call it using |
Generic workaround that should work for everybody without any other change: const retrySuspenseSWRMiddleware: Middleware = (useSWRNext: SWRHook) => {
return (key: string, fetcher, options) => {
if (options.suspense) {
const suspenseFetcher: typeof fetcher = async (fetcherOptions) =>
new Promise(async (resolve, reject) => {
async function revalidate(
revalidateOpts?: RevalidatorOptions
): Promise<boolean> {
const { retryCount = 0, dedupe = true } = revalidateOpts ?? {};
try {
const data = await fetcher(fetcherOptions);
resolve(data);
return true;
} catch (error) {
options.onErrorRetry(error, key, options, revalidate, {
retryCount: retryCount + 1,
dedupe,
});
}
}
try {
await revalidate();
} catch (error) {
reject(error);
}
});
return useSWRNext(key, suspenseFetcher, options);
}
return useSWRNext(key, fetcher, options);
};
}; and then use it with |
Bug report
I use
swr
withgraphql-request
and I am struggling with the automatic retry on an api error. Only a single request is made until the error is raised to my ErrorBoundary. If I set{ suspense: false }
two requests are made and the data shows up as expected.Expected Behavior
I would expect that
swr
handles the retry also in suspense mode. From the outside any retry should behave as a very long running request.I created a codesandbox to hopefully make the problem a bit more understandable:
https://codesandbox.io/s/swr-suspesnse-retry-bug-sqpjyn?file=/src/App.js
Additional Context
@testing-library/[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
The text was updated successfully, but these errors were encountered: