LourensVeen
commented
8 years ago I think we need to know what these things really mean first. It seems that there are four things here: the state of the workflow execution, the result of the workflow execution, the reason for failure, and whether it makes sense to retry the job unchanged:
State
- Waiting
- Running
- (Finished)
Result
- Success
- Failed
Reason
- Canceled
- SystemError
- (WorkflowError)
Run again
- SystemError
- TemporaryFailure
- PermanentFailure
CWL specifies that permanentFailure is returned for e.g. invalid expressions in the workflow document. How to interpret the return value of a command line tool can be specified by the creator of the workflow. So I think if we're using CWL for the workflows, then we need at least Success, PermanentFailure and TemporaryFailure as possibilities, otherwise we'd be incompatible with some workflows. If the job ends due to some external circumstance, then we can have additional error messages. And we'd like to combine things into a single list.
So that leads to
- Waiting
- Running
- Finished
- Success
- Failed
- Canceled (don't run again, probably)
- SystemError (run again)
- CWL TemporaryFailure (run again)
- CWL PermanentFailure (don't run again)
Which can then be simplified to
- Waiting (job in queue, VM suspended, etc.)
- Running
- Success (completed, system worked fine, CWL status success)
- Canceled (due to user action, no CWL result)
- SystemError (compute resource on fire, no CWL result)
- TemporaryFailure (system worked fine, CWL status temporaryFailure)
- PermanentFailure (system worked fine, CWL status permanentFailure)
So I propose replacing Failure with PermanentFailure, and using the above semantics to determine when to return what.
nielsdrost
According to the CWL spec, workflows can end in either success, temporaryFailure, or permanentFailure. We now have Waiting, Running, Success, Canceled, TemporaryFailure, Failed, and SystemError. Those should be reconciled somehow.