-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hold: unhold completed tasks with final task statuses #6141
Comments
I think we do. Take this one:
if you hold both This is arguably the correct behaviour. Interestingly the other task sticks around even with the change in output of Perhaps we should test for retries before putting a killed task on hold? |
I'm not sure your example applies to the issue @dwsutherland ?
If you hold Retriggering Having both |
Extending your scenario a bit (beyond what you described at least):
So the behaviour is consistent with what the datastore shows. But we should consider releasing the hold when a task is removed from |
If a task is manually killed, we put it into the held state.
This is an intentional feature as it suppresses automatic retries which are not likely to be desired in this case.
However, when the task reaches a final status, completes it outputs and is removed from the task pool, it remains in the held state in the data store. This is ok but a tad counter intuitive.
Suggest resetting the held state before removing a task from the pool to ensure that the task is not marked as held in the data store when it drifts into the n=1 window.
I don't think we preserve the held state once a task has left the pool (fact check this), so I think this is a more correct solution. Otherwise you might expect this task to remain held in a subsequent flow.
The text was updated successfully, but these errors were encountered: