Closed valeriangalliat closed 1 year ago
@valeriangalliat is attempting to deploy a commit to the Gladly Team on Vercel.
A member of the Team first needs to authorize it.
The latest updates on your projects. Learn more about Vercel for Git βοΈ
Name | Status | Preview | Comments | Updated |
---|---|---|---|---|
nfa-example | β Ready (Inspect) | Visit Preview | π¬ Add your feedback | Mar 9, 2023 at 8:15PM (UTC) |
@valeriangalliat Thanks for the PR!
The try/catch behavior makes sense and would be good to merge. Could you break that into its own PR?
I don't think we should add fetch-retry
as a dependency, given that developers might prefer other fetch implementations and it'll add to bundle size. Instead, I see two alternatives:
fetcher
function as an input. E.g., how SWR does this: https://swr.vercel.app/docs/data-fetching#fetchThat makes sense! I like the idea of the fetcher
function. I'll split the changes and make another PR for that early next week π
@kmjennison updated! This PR now only includes catching of fetch errors
Patch coverage: 100.00
% and no project coverage change.
Comparison is base (
f46d5ed
) 99.25% compared to head (8fb6693
) 99.25%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Diff best viewed in ignore whitespaces mode.
Handle fetch top-level errors
This PR wraps the
await fetch
calls to login and logout API endpoints by atry/catch
block so that we callonLoginRequestError
andonLogoutRequestError
not-only in case of HTTP errors, but also in case of network errors (e.g.fetch
rejecting withTypeError: failed to fetch
), instead of leaving those unhandled.~Retry network errors~
Moved to its own PR
Also in order to mitigate network errors, this PR introduces a retry logic when calling the login and logout API endpoints, provided by [fetch-retry](https://www.npmjs.com/package/fetch-retry). This module defaults to retrying up to 3 times at 1s intervals, and only retrying network errors (the case where `fetch` rejects, as opposed to HTTP errors where it resolves with `response.ok = false`). I think those defaults are sensible, and I added a configuration option `fetchRetryConfig` to allow fine tuning the retry logic if needed.I think the rate of fetch network errors I'm seeing on login API calls is exacerbated by the fact the login API is called on every page (https://github.com/gladly-team/next-firebase-auth/issues/424 - I tried coming up with a solution for that too but didn't find a reliable way to do that just yet), nevertheless this PR shouldn't leave those errors unhandled, and thanks to the retry logic, should lower their frequency.
Let me know what you think and if you need me to make any edits!