windmill
windmill copied to clipboard
Flow error handling and recovery
There is currently a failure module defined for every flow value: https://github.com/windmill-labs/windmill/blob/9cff49af6f906cceb90690bbe56c03f2bda03917/backend/openapi.yaml#L4046 but it is ignored by the current implementation
A first step would be to trigger this module on error and pass it the result of the step having error (or input transform) as:
{
error: "the error message",
step: <step number>, i
input_transform_field: optional<str>
}
@sqwishy New idea of a spec:
Extending FlowValue with the field:
interface RetryPolicy {
immediately: { attempts: int, delay?: int (seconds) }
exponential_backoff: { attempts: int, constants?: int (seconds, default = 10) }, where the delay is computed as (attempts_including_immediately^2 * constants)
}
retry_policy?: RetryPolicy
Everytime we retry we retry at the step that failed with the same input/state flow. Everytime we retry, the queue job is tagged with the error that caused this retry (field retry_error: jsonb ?) Once we run out of retries and once only, we trigger the failure module with the error and step at which it happened.
@rubenfiszel immediately has a delay which implies it's not immediate but just a constant delay as opposed to exponential delay?
how about
{
"constant": {
"seconds": 0
},
"exponential": {
"multiplier": 1,
"seconds": 0
}
}
where exponential delay is calculated as multiplier * seconds ^ failures
👍
On Fri, Aug 19, 2022, 21:51 sqwishy @.***> wrote:
how about
{ "constant": { "seconds": 0 }, "exponential": { "multiplier": 1, "seconds": 0 } }
where exponential delay is calculated as multiplier * seconds ^ failures
— Reply to this email directly, view it on GitHub https://github.com/windmill-labs/windmill/issues/275#issuecomment-1221042843, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACDJADTGRT5GW5VRVLAVULVZ7QSFANCNFSM55C7JJRA . You are receiving this because you were mentioned.Message ID: @.***>