-
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:
|
f3587d1
to
55c71a9
Compare
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
Simplify integration test
Co-authored-by: Ronnie Dutta <[email protected]>
Co-authored-by: Ronnie Dutta <[email protected]>
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 |
@@ -1703,7 +1740,7 @@ async def _main_loop(self) -> None: | |||
self.broadcast_mgr.check_ext_triggers( | |||
itask, self.ext_trigger_queue) | |||
|
|||
if itask.is_ready_to_run(): | |||
if itask.is_ready_to_run() and not itask.is_manual_submit: |
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.
What is the reason for this change?
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 because manual submits may now bypass the queue, they get pushed through the submission pipeline (lines 1440-1450 above).
Co-authored-by: Ronnie Dutta <[email protected]>
(I ran out of time today, but I just need to tweak the tests as requested by @MetRonnie ... ) |
Close #5963
Supesede #6192 (it was getting messy)
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.