-
Notifications
You must be signed in to change notification settings - Fork 94
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
Trigger now if workflow paused #6499
base: master
Are you sure you want to change the base?
Conversation
98d500e
to
3dc032c
Compare
Status of this PR:
|
55c71a9
to
0372d91
Compare
Does this mean if I trigger when paused, and a queue limit is reached, that it will enter a queue but not be released when the queue "empties" of running tasks? Will test. |
Yes. Pausing the scheduler halts all automatic job submission, so that means queued tasks won't automatically run. But if you want the queued task to run before resuming the workflow you can just trigger it again before resuming. |
645707c
to
02f1a22
Compare
(I've just tweaked the |
02f1a22
to
cb03ae0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
# set --pre=all should not cause a task to submit in a paused workflow | ||
assert len(submitted_tasks) == 0 | ||
# but triggering it should | ||
schd.pool.force_trigger_tasks(['1/a'], []) | ||
schd.release_tasks_to_run() | ||
assert len(submitted_tasks) == 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please could you put this new bit in a separate test and revert the splitting of trigger
and set
from this test; a key feature of this test was that is checks equity between trigger
and set
for the same flow nums
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I split that into separate tests is that this PR changes that equivalence.
Trigger and set (in a paused workflow) are more similar on master, because a triggered task does not become "active" until the workflow is resumed, so it can be triggered multiple times to absorb multiple flow numbers. On this branch, a triggered task becomes active immediately and so subsequent triggers get ignored.
In light of that, do you still want me to revert that? I suppose we could have a combined test for what is common, and separate tests for the behavior that differs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In light of that, do you still want me to revert that? I suppose we could have a combined test for what is common, and separate tests for the behavior that differs.
👆 That
That issue is confusing. I think the "bug" initially reported by Tom is just the expected double-trigger requirement to get past a queue. In his description, despite the tasks being held, they did run on the second trigger attempt - but he had expected that manual trigger would skip queues to run immediately after just one attempt. So I presume you're referring to the presumably-actual-bug that you commented on part way through the discussion: #6398 (comment) ... I've commented there, as I'm not sure this PR is relevant: #6398 (comment) |
No, there is definitely a bug lurking here. I have added an example to the issue in which task doesn't run when triggered (no queue limiting in effect), however, on this branch the task does run (entering an infinite kill/trigger loop). So it looks like this closes #6398 (congrats on fixing a bug you didn't think existed!). |
Test added on master failing - need to merge master into this branch |
Great, well done me. I'll add a close directive to the description above... |
(will see if I can get a test for this, ..., hjoliver#61) One recently added test is failing: FAILED tests/integration/run_modes/test_skip.py::test_doesnt_release_held_tasks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider this approved pending addressing of comments (including #6499 (comment))
(have manually run the auto-restart tests on this branch, they all pass) |
if self.pool.tasks_to_trigger_on_resume: | ||
# and manually triggered tasks to run once workflow resumed | ||
pre_prep_tasks.update(self.pool.tasks_to_trigger_on_resume) | ||
self.pool.tasks_to_trigger_on_resume = set() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think codecov is right, these lines are untested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, I was waiting for agreement to add the option before adding tests for it, then failed to come back to the PR till now.
Co-authored-by: Ronnie Dutta <[email protected]>
Co-authored-by: Ronnie Dutta <[email protected]>
Co-authored-by: Ronnie Dutta <[email protected]>
Co-authored-by: Ronnie Dutta <[email protected]>
Co-authored-by: Ronnie Dutta <[email protected]>
Co-authored-by: Ronnie Dutta <[email protected]>
Co-authored-by: Ronnie Dutta <[email protected]>
d00915e
to
bdbcaa0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved pending resolution of Ronnie's comment above and, ideally, some kind of test for the --on-resume
option.
Close #5963
Supesede #6192 (it was getting messy)
Close #6398
New behaviour for triggering when the workflow is paused
DEFAULT: run triggered tasks NOW even if the workflow is paused
OPTION:
--on-resume
- run triggered tasks only when the paused workflow is resumedImplementation:
tasks_to_trigger_(now|on_resume)
lists, after state reset and queue wranglingCheck List
CONTRIBUTING.md
and added my name as a Code Contributor.setup.cfg
(andconda-environment.yml
if present).?.?.x
branch.