Replies: 2 comments
-
I want to be careful with issues like this - having flows and tasks mirror each other isn't a worthy goal in and of itself; for example, what errors should a flow retry on that wouldn't be better encapsulated and caught within a task? We need to have principled motivations for these interface extensions, not just matching the concepts for its own sake. I'm not suggesting that some part of this issue isn't worthwhile, but the motivation is lacking to me. |
Beta Was this translation helpful? Give feedback.
-
I'm converting this issue to a discussion to allow for a more open-ended conversation about the proposed flow retry enhancements. As @cicdw pointed out, we need to explore more principled motivations and specific use cases for this functionality at the flow level. We invite contributors to share:
This discussion will help us evaluate whether and how to implement these features. We look forward to a productive conversation! |
Beta Was this translation helpful? Give feedback.
-
First check
Describe the current behavior
Flows retries don't include a custom retry function option.
Retry delay options don't include a list of values, jitter, or exponential backoff.
This expands #9139 quite a bit, so closing that issue.
Describe the proposed behavior
Example use of expanded retry delay behavior:
Example Use
Better flexibility and better outcomes. Also less surprising behavior for flows if functionality matches tasks.
Additional context
No response
Beta Was this translation helpful? Give feedback.
All reactions