[galaxy-dev] Galaxy not recording return codes (error levels)
Dear all, Is there a plan to record the return code (error level) in the Galaxy Job history, along with the stdout and stderr strings? I would find this very useful - especially for situations where a job is killed (e.g. by the OS) and there is no indication of why it died (stderr is empty). Thanks, Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Galaxy not recording return codes (error levels)
Somewhat related, can I make a feature request that in the job attribute editor screen (i.e. what you get when you click the pencil icon in the top right corner of a history item), you can manually change the state of a job from failed (which means you can't use the output in any subsequent analyses), to ok? On 2012-09-21 7:54 AM, Peter Cock p.j.a.c...@googlemail.com wrote: Dear all, Is there a plan to record the return code (error level) in the Galaxy Job history, along with the stdout and stderr strings? I would find this very useful - especially for situations where a job is killed (e.g. by the OS) and there is no indication of why it died (stderr is empty). Thanks, Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Galaxy not recording return codes (error levels)
Just to be clear, whenever a tool's stdio rules are triggered there should be messages prepended to stdout and/or stderr. If a tool defines a stdio regular expression and the regular expression matches on stdout, a message should be prepended to stdout. However, these will be empty if tools without stdio sections fail (which is true for most tools at this time). What you're asking for is to include the return code in the history panel. It might make more sense to include this kind of information in the View Details (which you get by clicking on the job name and then clicking the i button). That way there's less clutter and it's still easy to get to failures (which hopefully aren't happening very often). What do you think? -Scott - Original Message - Dear all, Is there a plan to record the return code (error level) in the Galaxy Job history, along with the stdout and stderr strings? I would find this very useful - especially for situations where a job is killed (e.g. by the OS) and there is no indication of why it died (stderr is empty). Thanks, Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Galaxy not recording return codes (error levels)
On Friday, September 21, 2012, Scott McManus wrote: Just to be clear, whenever a tool's stdio rules are triggered there should be messages prepended to stdout and/or stderr. If a tool defines a stdio regular expression and the regular expression matches on stdout, a message should be prepended to stdout. However, these will be empty if tools without stdio sections fail (which is true for most tools at this time). What you're asking for is to include the return code in the history panel. It might make more sense to include this kind of information in the View Details (which you get by clicking on the job name and then clicking the i button). That way there's less clutter and it's still easy to get to failures (which hopefully aren't happening very often). What do you think? -Scott Yes, it was the info section I had in mind too :) I agree this wouldn't be needed on the normal history or peep view. However it would also be good to show on the bug view for failed datasets. (And to store it as a new column in the database for advanced queries) Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Galaxy not recording return codes (error levels)
Yes,as long as this happens soon, it is a safe assumption that almost all existing tools ignored the return code (because they couldn't use it till recently). Or allow the error code field to be null in the database (shown as blank or not available in the web interface). Peter On Friday, September 21, 2012, Scott McManus wrote: Excellent. :) I had considered adding an exit code column but had avoided touching the database at first. Migration could be a little tricky. If we assume that there are few (or even zero) tools checking stdout/stderr/exit codes, then we could assume that a job failed if it had any stderr text. Then we would need appropriate backfilled exit codes - say, 0 for success and -1 for error. Would that make sense? -Scott ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Galaxy not recording return codes (error levels)
Good - after taking a step back I thought it seemed better to leave everything null rather than guess at an exit code. Does anyone have any objections to adding an exit code column with null values for previously-executed jobs? -Scott - Original Message - Or allow the error code field to be null in the database (shown as blank or not available in the web interface). Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
