minimap2 accepts invalid fastq records

[mdkeehan]

I was rather horrified to discover that minimap2 will do a lot of processing with an invalid fastq.
I was fishing out a subset of reads from a large pacbio fastq file.
The grep statement was wrong and resulted in some malformed fastqs. These were then processed by minimap2.

someone@somehost:/somedir/git/minimap2/test$ cat t2-with-malformed.fq 
@t2-with-chopped-quals
GGACATCCCGATGGTGCAGgtGCTATTAAAGGTTCGTTTGTTCAACGATTAAagTCCTACCTGTACGAAAGGAC
+
++++++++++++
@t2-nothing-wrong
GGACATCCCGATGGTGCAGgtGCTATTAAAGGTTCGTTTGTTCAACGATTAAagTCCTACCTGTACGAAAGGAC
+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
fred.fq:@t2-greppedfrom fred*.fq
fred.fq:GGACATCCCGATGGTGCAGgtGCTATTAAAGGTTCGTTTGTTCAACGATTAAagTCCTACCTGTACGAAAGGAC
fred.fq:+
fred.fq:++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
@t2-with-extra-quals-from-grep-group-separator
GGACATCCCGATGGTGCAGgtGCTATTAAAGGTTCGTTTGTTCAACGATTAAagTCCTACCTGTACGAAAGGAC
+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
--

Minimap2 will happily parse these records.

I suggest at a minimum check that the qual-score length = base length when reading the fastq and then terminate as soon as possible so the user can investigate.

Clearly the default grep group separator is a pathological case as it is a valid and common pacbio quality score character.

[lh3]

fd64dd2 warns about incorrect records.