Bowtie2: Improve datatype mismatch error detection, job failure, and bug report content

[jennaj]

Test history: https://usegalaxy.org/u/jen/h/compressed-uploaded-fq-tests

Details: galaxyproject/galaxy#3511 (comment)

HISAT2 has a similar issue #1790

[mvdbeek]

I don't think we should do that in the tool, if a user wants to fail by selecting the wrong datatype on purpose they should be able to do that. Same for #1790. I'd also argue that this doesn't happen in real life until there is a report. I'd be in favor of closing this.

[jennaj]

Ok, if you think that is best.

The FastQC wrapper does tell a user when there is a problem with interpreting the input - thought we could model after that.

• So.. if we leave it, some tool errors and the extended bug reports have the reason why buried in with other stderr/stdout, which is helpful and maybe enough. FastQC does that.
• These two tools produce green success datasets, with no other clues about what is going wrong - just zero reads mapped in log (if log is output). Bowtie2 and HISAT2 do this. I'll just watch bug reports and come back to this if the improved datatype sniffing doesn't help users to understand what is going wrong & the tools get reported often (going forward).

galaxyproject/galaxy#3511 (comment)

[mvdbeek]

These two tools produce green success datasets, with no other clues about what is going wrong - just zero reads mapped in log (if log is output)

Alright, that is a bug.

[nsoranzo]

@jennaj The bowtie2 wrapper you're using in your history is version 2.2.6.2, any chance this is fixed in the latest one (2.3.4.1)?

[jennaj]

Updated tests for Bowtie2 v 2.3.4.1, same history, data 43-47 retested in data 74-77 (using the unhidden version of the same input data, see below for how hidden datasets show up during re-run/version switch).

The results are still "green/success" but if the mapping stats are output, the user is warned there. It might be better if these just failed (red) or at least the BAM was not usable with downstream tools, it only contains the header...

Hidden datasets related to compressed inputs, available in the input select, came out during testing so seems worth reporting - not sure if a Galaxy problem or a tool problem. What do you both think? Where should this be reported? Couldn't test if HISAT2 does this since it wasn't updated.

Details: Bowtie version v 2.2.6.2, when brought up with a rerun, does not list the "hidden" datasets behind the compressed version in the input select. However, if you switch to v 2.3.4.1, the hidden dataset is selected by default. The end-user would need to know to change to the unhidden version or a tool error will occur (with inputs that have the correct datatype). If the tool is launched directly from the tool panel, no hidden datasets are in the select. Odd, yes? This looks like an older bug, maybe now only comes out with reruns/version changes.

2.3.4.1 loaded via tool panel, no hidden datasets in select menu:

2.2.6.2 loaded via rerun > version switch to 2.3.4.1 > now includes compressed hidden dataset in the select (Importantly, the hidden is selected by default, which would result in a tool error).

[jennaj]

Look like it may be related, or be a way of capturing an error state, rather than producing green, header-only bams when tools are given bad inputs. The issue is about pipes/error trapping: #1733

(unlink if not really related - I haven't reopened this ticket, nor the HISAT2 one)