Hi Stian, Alan, reply is in line:
> (No need to cc support@mygrid, we're all no dev@taverna :) Sorry :) > Perhaps valuable would be some kind of --fail-on-any-error option to > executeworkflow? This could then be enabled in the server. It could > bail out as soon as an error document appears at an output port. Yes, I am interested in a option like the --fail-on-any-error that when an activity tool fails the executeworkflow.sh fails too and the exit code of the activity is propagated to the exitcode of the executeworkflow. How can I set this option in taverna server 2.5? Using the admin panel? Best regards, Simone. ----- (No need to cc support@mygrid, we're all no dev@taverna :) The exit code from Taverna server reflects the exit code from executeworkflow.sh - which would be 0 unless the workflow engine itself failed. (e.g. the t2flow used a plugin that was not installed on the server, or a file was not found) The exit code of a individual tool within the workflow does not cause the workflow to fail, but rather it will propagate "Error Documents" on its outputs. Anything 'below' in the workflow expecting this value will then in turn produce derived Error Documents. This means that if the errror was within a list iteration, only that element of the list (and subsequent iterations) are replaced with errors. Similarly, the stdout and stderr of the individual tool (of which many could be running concurrently) is captured by the workflow engine and thus not shown in the stdout or stderr REST resources of the Server's executeworkflow execution. I just check the Tool Activity, and here it waits for the exit code: https://github.com/apache/incubator-taverna-common-activities/blob/master/taverna-external-tool-activity/src/main/java/org/apache/taverna/activities/externaltool/local/LocalToolInvocation.java#L384 You see it will provide the STDERR output as part of the exception (which then goes into the error document). It's configurable to allow certain exit codes, but this is not exposed in the UI. (Not so sure about that UnsupportedEncodingException handling there.. ) Perhaps valuable would be some kind of --fail-on-any-error option to executeworkflow? This could then be enabled in the server. It could bail out as soon as an error document appears at an output port. -- Simone Bnà, PhD C++ Software Developer, CINECA Via Magnanelli 6/3, 40033 Casalecchio di Reno, Italy office: +39-0516171938 email: [email protected]/[email protected]
