Flow error handling and recovery

[rubenfiszel]

There is currently a failure module defined for every flow value:

windmill/backend/openapi.yaml

Line 4046 in 9cff49a

failure_module:

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> 
}

[rubenfiszel]

@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.

[sqwishy]

@rubenfiszel immediately has a delay which implies it's not immediate but just a constant delay as opposed to exponential delay?

[sqwishy]

how about

{
  "constant": {
    "seconds": 0
  },
  "exponential": {
    "multiplier": 1,
    "seconds": 0
  }
}

where exponential delay is calculated as multiplier * seconds ^ failures

[rubenfiszel]

👍

…

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 <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACDJADTGRT5GW5VRVLAVULVZ7QSFANCNFSM55C7JJRA> . You are receiving this because you were mentioned.Message ID: ***@***.***>