feat: error retry handling #49
Conversation
| @@ -36,6 +36,10 @@ const baseSchema = z.object({ | |||
| IPFS_GATEWAYS_URL: stringToJSONSchema | |||
| .pipe(z.array(z.string().url())) | |||
| .default('["https://ipfs.io"]'), | |||
| RETRY_MAX_ATTEMPTS: z.coerce.number().int().min(1).default(3), | |||
| RETRY_BASE_DELAY_MS: z.coerce.number().int().min(1).default(3000), // 3 seconds | |||
| RETRY_FACTOR: z.coerce.number().int().min(1).default(2), | |||
There was a problem hiding this comment.
is it possible to mark these three as optional within schema chaining since they're technically not required?
There was a problem hiding this comment.
with the default() they are optional, you are not forced to pass them
| @@ -0,0 +1,40 @@ | |||
| export interface ErrorContext { | |||
There was a problem hiding this comment.
In the future it would be good to implement more specific error contexts depending on the class/functions throwing the errors so that you don't have a ton of optional params (maybe a bit too generic)
There was a problem hiding this comment.
could be, i wanted to keep it simple for now
| * @param options.baseDelay - Initial delay in milliseconds (default: 5000) | ||
| * @param options.factor - Multiplier for exponential increase (default: 2) | ||
| * @param options.maxAttempts - Maximum number of retry attempts (default: 3) |
There was a problem hiding this comment.
These are technically not required though right?
There was a problem hiding this comment.
yeah, i mean you can avoid passing the options object and have the default being set
| * - Registry tracking of supported/unsupported strategies and events | ||
| * | ||
| * TODO: Enhance the error handling/retries, logging and observability |
| */ | ||
| private addJitter(delay: number): number { | ||
| // Random value between 0.8 and 1.2 | ||
| const jitterFactor = 0.8 + Math.random() * 0.4; |
There was a problem hiding this comment.
Could the delta for 1 ± delta be configurable too?
There was a problem hiding this comment.
could be, will add it to Linear as improvement (isn't critical now)
🤖 Linear
Closes GIT-223 GIT-224 GIT-110
Description
We implement a RetryHandler with ExponentialBackoff for handling error retries (centralized on the Orchestrator) and define two big base class of errors:
In the next PR, will adjust the different errors of the system and packages to extend from this classes accordingly
Checklist before requesting a review