Replies: 5 comments
-
|
Thanks for opening your first issue here! Be sure to follow the issue template! |
Beta Was this translation helpful? Give feedback.
-
|
How are you manually retrying the task? (There are at least two ways of doing this.) If you use clear, one of the options is to Include Downstream |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to clear all downstreams though, and I guess that's the crux of the problem, some of those tasks have been allowed to execute even if the current task failed. I guess exploring it a bit more, the "failed" option on clearing downstream solves some of this issue, so there might be a solution to his "problem" already. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @thejens, I have a different issue but it is also related to the situation where full recursive clearing of downstream tasks is undesirable. In your case, would having the option to clear only downstream tasks with "upstream failed" solve your issue? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's indeed a solution, I'd go as far as saying that should happen automatically when upstream succeeds |
Beta Was this translation helpful? Give feedback.
-
Description
When manually retrying a failed task, and it succeeds, the downstream tasks with an "upstream_failed" state should be reset, or possibly added to a new/different state as the upstream is now indeed successful. This also applies when manually setting the task to success.
Use case / motivation
When retrying a failed task so it succeeds, or manually setting it to success, I believe the default expected behaviour is for downstream tasks to be automatically "unblocked". I realize the current behaviour of retaining the "upstream_failed" state is in some cases desired, but I believe those situations are in minority.
The best example would be a task that has several branches of downstream tasks. When it fails, all those branches fail with "upstream_failed". Once the task is manually set to success (or manually re-triggered) it is sometimes painful to go through all those downstream branches and clear them one-by-one, especially for more complex workflows where the recursive clearing might be too aggressive.
My current workaround is to manually search for all upstream_failed tasks and clear them from the tasks overview interface, or to use recursive clear on the now successful "root" task, then quickly marking it back to success before it re-triggers.
Are you willing to submit a PR?
Yes! But I wouldn't know where to implement this.
Related Issues
n/a
Beta Was this translation helpful? Give feedback.
All reactions