-
Notifications
You must be signed in to change notification settings - Fork 313
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
feat(shared): Replace callWithRetry
and runWithExponentialBackoff
with retry
#5144
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: c48f5d3 The changes in this PR will be included in the next version bump. This PR includes changesets to release 20 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
110a8c3
to
f0aa6ed
Compare
!allow-major |
packages/shared/src/retry.ts
Outdated
retryImmediatelyOnce: boolean; | ||
/** | ||
* The delay for the immediate retry. | ||
* @default 100 | ||
*/ | ||
retryImmediatelyDelay: Milliseconds; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two options feel weird, I can't put a finger on it but this seems like something that should be only one option and be renamed.
- Retrying immediately already implies that it can only happen once, right? Afterwards it's not immediate anymore
- Technically "immediate" would be a delay of 0 so the current default of 100 is already quite arbitrary. Why should we need to change this from a case by case basis?
So I'd just put those two options into one called retryImmediate: boolean
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tagging @panteliselef as he was also interested about this - Im also open to suggestions to improve this further.
There are at least two cases where we might want to immediately retry, before applying the backoff strategy:
- mission-critical operations that need to be completed as fast as possible
- transient errors on the network level (think about mobile devices)
This property decouples the immediate retry with the rest of the backoff logic, as its very hard to tune the options using a combination of factor + initialDelay otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to merge these two into a single retryImmediately: boolean
with a default delay of 100ms
. If we ever need to change this, we can add a new prop then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
f0aa6ed
to
6dc4e5d
Compare
6dc4e5d
to
b0646a7
Compare
… with `retry` utility
b0646a7
to
b1f5bc5
Compare
Co-authored-by: Lennart <lekoarts@gmail.com>
Co-authored-by: Lennart <lekoarts@gmail.com>
Co-authored-by: Lennart <lekoarts@gmail.com>
@@ -137,8 +137,8 @@ export async function loadClerkJWKFromRemote({ | |||
reason: TokenVerificationErrorReason.RemoteJWKFailedToLoad, | |||
}); | |||
} | |||
const fetcher = () => fetchJWKSFromBAPI(apiUrl, secretKey, apiVersion); | |||
const { keys } = await callWithRetry<{ keys: JsonWebKeyWithKid[] }>(fetcher); | |||
const fetcher = () => fetchJWKSFromBAPI(apiUrl, secretKey, apiVersion) as Promise<{ keys: JsonWebKeyWithKid[] }>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ why do we need to cast here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
Description
callWithRetry
withrunWithExponentialBackOff
so we only have a single retry mechanism in userunWithExponentialBackOff
toretry
for clarityrunWithExponentialBackOff
:retryImmediately
(boolean): Controls whether the helper should retry the operation immediately. If true, the exponential backoff delay will start only once this retry is over. Defaults to true.jitter
(boolean): If true, the intervals will be multiplied by a factor of[1,2]
. Defaults to true.Checklist
pnpm test
runs as expected.pnpm build
runs as expected.Type of change