Marta Villegas asked on taverna-users 2011-09-09:
I'm using "merge string list to a string" component to concatenate a list of outputs in most of our workflows. We do that because it's more user friendly to copy that output with all results than coping each element of the list.
We work with lists with more than 500 elements.
The problem comes when some elements have an error, then "merge string list" is not able to create the concatenation and gives an error.
Here I attach an example workflow that shows the problem...
the exected result without errors would be a list like:
with errors the result now is:
[an error message]
I would like to have:
Currently beanshell scripts (and thus local workers) can't deal with errors. This is partly due to T2-1099 - but also because the ErrorBounce layer prevents errors from reaching the service.
A quick win for achieving this would be a new shim "Remove errors" that can strip out errors from a list - or "Replace error" which can take an error and replace it with a string value (by default ""). Ideally "Merge string list to a string" should be able to deal with errors directly - but it would have to be configured with what the replacement value should be.
One would also need to change the configuration UI of ErrorBounce to allow passing errors in.
Error handling dispatch layer
(We've had a discussion about the ideal "error handling dispatch layer" - see Stian's summary from the list
When we earlier talked to some users about what options they wanted for error handling, we considered:
a) Removing errors from the list (skipping them)
b) Replacing errors with a replacement input value, e.g. "myStandardGene", empty string, etc.
c) Replacing calls on errors with a replacement output value, e.g. "-- ERROR HERE!!--"
The consideration was not conclusive, but roughly each of these come with issues:
a) Breaks the order of the list - result in position 5 might now come from position 7 in incoming list (5 & 6 were errors) - which makes it hard to use with later dot products
b) Not sure which "fake input" would work well in many cases - and could end up with "fake data" sneaking its way into the results
c) "Error message" values could be passed on to the next service, which don't know it's an error, and falls over with new errors or strange outputs, but these are no longer linked back to original error.
As engineers we thought that we could address c) by giving out the replacement output as "An error with a replacement value". The service which could fail would have an error handling configuration with "[x] Substitute errors with _my_value_____"
Thus the default for downstream services would be to fail (as of now) - but with a possible error handling configuration to "[x] Allow error replacement values" which would run using the provided replacement value. We were not sure if the outputs of such processors should then be normal values or "errors with replacement values".
We did not proceed with implementing any of these options, as they seemed to require a fair bit of effort and raised more open questions.
The feature suggested by this bug is however much easier to implement and would give immediate benefit to users.
A workaround is to define alternate services using Taverna 1, and then copy and paste.
The only workaround I can think of would be to use the "Failover" mechanism - specifying an alternate service to the one that occasionally fails. Unfortunately the Taverna 2 user interface does not yet show this feature -
http://www.mygrid.org.uk/dev/issues/browse/T2-294 suggests creating that processor in Taverna 1 and then use Copy and Paste. See http://www.mygrid.org.uk/usermanual1.7/workbench_windows.html#ame_alternate_processors for Taverna 1 documentation.
See attached where I have manually edited the .t2flow to add a string constant as an alternate service to "Sometime fails". (Note that the alternate service would need to provide values for all the service outputs - and at the same list depth)