CQ7 - Outcome about workflow-run-crate HOT 5 CLOSED

The StreamFlow implementation is already using actionStatus on CreateAction instances (both the workflow run and the tool runs). Other actions represented in the profiles are the step executions (ControlAction) and the workflow engine execution (OrganizeAction).

One could try to be as precise as possible and mark failures (actionStatus: FailedActionStatus and optionally error: <ERROR DESCRIPTION>) exactly where they happen. So if the workflow engine itself fails (e.g., bad parameters passed to the cwltool executable, or a cwltool bug), there should be a failure in the OrganizeAction, and the other actions should probably be missing altogether from the crate. Similarly, if an error can be ascribed to the workflow's own code (and not to one of the tools it orchestrates), then there should be a failure in the workflow's CreateAction, and actions corresponding to steps / tools that were not executed should be missing. When does a step execution (ControlAction) fail? In this case the instrument is the step itself, i.e., a logical section of the workflow. In principle it could be said that the error happens exactly in the step execution (and not in the tool execution) if the tool does not even begin to run, i.e., the failure happens while the step is "being prepared". This could be hard to pinpoint: some workflow engines might not even have a step preparation concept. Mapping errors in the execution of the tool (either the wrapper or the wrapped command) is more straightforward: they should be reported in the corresponding CreateAction.

Another thing to consider is dependencies between the actions. For instance, if a step fails, then the workflow also fails; If a tool fails, then the corresponding step and the workflow also fail.

We should try to avoid making things too complicated in the profiles, making sure they stay flexible. I think the main things to cover are:

• Recommend using CompletedActionStatus for successful actions and FailedActionStatus for failed ones; in the latter case, a consumer should not assume the presence of object / result in the action, nor the presence of dependent actions in the crate
• Recommend propagating FailedActionStatus to dependent actions
• Don't make specifying actionStatus a MUST, but say that consumers will assume a successful action in this case
• Specifying error needs to be optional (additional information might not be available)

I would leave ActiveActionStatus and PotentialActionStatus out for now.

from workflow-run-crate.

Success = Exit status is zero

from workflow-run-crate.

This is already detailed in https://www.researchobject.org/ro-crate/1.1/provenance.html#recording-changes-to-ro-crates, so we can simply direct the reader there for the JSON-LD details. We just need to add the recommendation to use FailedActionStatus if there was an error (unhandled exception, non-zero exit status) and CompletedActionStatus otherwise. Maybe we should also say that for failed executions the action's object and result could be empty / missing or incomplete.

from workflow-run-crate.

Agree to use actionStatus as proposed.

How to show the error message: https://schema.org/error on the CreateAction of tool or ControlAction of the step? Do both of them fail?

Additionally intermediary provenance while a workflow is running could have ActiveActionStatus showing PotentialActionStatus for steps not executed yet.

from workflow-run-crate.

Another thing to consider is dependencies between the actions. For instance, if a step fails, then the workflow also fails; If a tool fails, then the corresponding step and the workflow also fail.

As discussed at the last meeting, this is not always true due to the fault tolerance featured by some engines.

from workflow-run-crate.