Hi there
Does it make sense for there to be a Reset state -> submitted option?
I’ve been working with a colleague and this seems to cause the task to simply hang in that state and never run. Once we tried Reset state -> waiting, everything ran fine.
All the best
Jonny
Hi @jonnyhtw,
The Cylc 7 GUI shows “task proxy” objects inside the scheduler that represent the abstract tasks of the workflow. Their state gets updated by activity in the scheduler (e.g. task job just submitted, hence “submitted” state) or by status messages received from running jobs (“started”, “succeeded”, “failed”).
The “reset state” command literally sets the state value to be what you ask, regardless what it really should be. That won’t have any material effect unless something depends on the new state.
Resetting a task to “waiting” may cause its job to submit, because the scheduling algorithm matches the unsatisfied prerequisites of waiting tasks with the completed outputs of running or finished tasks (so any waiting task will end up submitting if its prerequisites become satisfied).
Resetting a task to “succeeded” may allow the workflow downstream of it to continue, if you have a broken task that reported failure even though you know it completed its important work before it failed.
Resetting a task to “submitted” is not something that users should ever need to do, however. It just makes it look as if the job was already submitted, and the scheduler will therefore wait for the supposedly-submitted job to send its “started” status message.
If your colleague wants the job to submit, regardless of prerequisite state etc., use the trigger command.
Hilary
p.s. Cylc 8 (coming soon) has a more straightforward and powerful scheduling model, and “state reset” will no longer be a thing … so that potential source of confusion (and others) will soon be gone.
thanks for the detailed info hilary! that basically coincides with what i thought but i certainly didn’t all the details.
i look forward to having a play with cylc 8!
cheers
jonny
