Actions
Bug #21993
closedWorkflow runner keeps running when its only subprocess is "on hold" (state=queued, priority=0)
Status:
Resolved
Priority:
Normal
Assigned To:
Category:
CWL
Target version:
Story points:
-
Release:
Release relationship:
Auto
Description
Steps to reproduce:
- Launch a workflow that starts with a single step (e.g.: revsort) and wait for the wf runner instance to start
- Wait for the subprocess appears as Queued
- Cancel the subprocess
The workflow runner instance will keep running indefinitely. Not sure if it's a-c-r's job to realize that it should cancel itself.
Files
Updated by Lucas Di Pentima 7 months ago
- Description updated (diff)
- File stuck-wf.png stuck-wf.png added
Updated by Brett Smith 7 months ago
- Related to Bug #20985: Setting priority 0 on a queued container should change it to "cancelled" state added
Updated by Peter Amstutz 7 months ago
Yes, arvados-cwl-runner should notice that the priority went to 0 and do something about it.
Updated by Peter Amstutz 6 months ago
21993-wf-step-cancel @ e19c1309aa6bad138479da3a3a5dd737fca400b7
- All agreed upon points are implemented / addressed.
- workflow steps cancelled before being run are now recognized and treated as failed steps
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- n/a
- Code is tested and passing, both automated and manual, what manual testing was done is described
- manually tested by running a workflow, cancelling the step in workbench, and observing the workflow runner didn't terminate. Then implemented the fix, went through the same process, and the cancelled (state: Committed, priority: 0) workflow step is now recognized as a failed step.
- Documentation has been updated.
- n/a
- Behaves appropriately at the intended scale (describe intended scale).
- no changes to scale
- Considered backwards and forwards compatibility issues between client and server.
- no issues, it now requests the 'priority' field from the container request, but that field has been in the container API from the very beginning
- Follows our coding standards and GUI style guidelines.
- yes
This is a straightforward bugfix, the only unusual thing is that it took so long to notice that there was a problem.
Unit testing currently doesn't really cover the main loop of the workflow runner. Integration tests do execute the main loop but it is difficult to test exceptional cases.
Updated by Peter Amstutz 6 months ago
- Status changed from In Progress to Resolved
Actions