Problem
Currently, expressing "retry an operation until it succeeds, restarting with modified input on error" requires manually composing handleErrorWith and repeat/untilRight, which is verbose and non-obvious for a common use case.
Proposal
Expose a helper function that simplifies the "retry on error" pattern. The goal is to allow users to easily express: "repeat this operation, and if it fails, restart with new input derived from the error."
Proposed API (options)
// Option 1: Explicit error handler
WIO
.repeat(a)
.untilSuccess
.onErrorRestartWith(err => newInput)
// Option 2: untilRightWithError variant
WIO
.repeat(a)
.untilRightWithError
// Option 3: Chained modifier
WIO.repeat(a).usingError.untilRight()
Underlying Implementation
This would desugar to something like:
WIO.repeat(
a.handleErrorWith(err => err.input: Out | In)
).untilRight(...)
Use Case
Common in workflows where an operation may fail transiently and should be retried, potentially with adjusted parameters based on the failure reason (e.g., backoff, corrected input, alternative strategy).
Open Questions
- Best naming/syntax for the API
- Should error-to-input transformation be required or optional (with identity as default)?
Important!
This requires some API design capability, dont try to follow examples above blindly
Problem
Currently, expressing "retry an operation until it succeeds, restarting with modified input on error" requires manually composing
handleErrorWithandrepeat/untilRight, which is verbose and non-obvious for a common use case.Proposal
Expose a helper function that simplifies the "retry on error" pattern. The goal is to allow users to easily express: "repeat this operation, and if it fails, restart with new input derived from the error."
Proposed API (options)
Underlying Implementation
This would desugar to something like:
Use Case
Common in workflows where an operation may fail transiently and should be retried, potentially with adjusted parameters based on the failure reason (e.g., backoff, corrected input, alternative strategy).
Open Questions
Important!
This requires some API design capability, dont try to follow examples above blindly