Uh oh!
There was an error while loading. Please reload this page.
feat(shared): Replace callWithRetry and runWithExponentialBackoff with retry - #5144
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
f0aa6edComparenikosdouvlis
commented
Feb 13, 2025
!allow-major |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| retryImmediatelyOnce: boolean; | ||
| /** | ||
| * The delay for the immediate retry. | ||
| * @default 100 | ||
| */ | ||
| retryImmediatelyDelay: Milliseconds; |
There was a problem hiding this comment.
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.
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.
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
Uh oh!
There was an error while loading. Please reload this page.
f0aa6ed to
6dc4e5dCompare6dc4e5d to
b0646a7Compare… with `retry` utility
b0646a7 to
b1f5bc5CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Lennart <lekoarts@gmail.com>
Co-authored-by: Lennart <lekoarts@gmail.com>
Co-authored-by: Lennart <lekoarts@gmail.com>
| } | ||
| const fetcher = () => fetchJWKSFromBAPI(apiUrl, secretKey, apiVersion); | ||
| const { keys } = await callWithRetry<{ keys: JsonWebKeyWithKid[] }>(fetcher); | ||
| const fetcher = () => fetchJWKSFromBAPI(apiUrl, secretKey, apiVersion) as Promise<{ keys: JsonWebKeyWithKid[] }>; |
Description
callWithRetrywithrunWithExponentialBackOffso we only have a single retry mechanism in userunWithExponentialBackOfftoretryfor 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 testruns as expected.pnpm buildruns as expected.Type of change