feat: skip too short reads #32
Conversation
There was a problem hiding this comment.
Something about this PR doesn't sit right with me, beyond my inline comments.
E.g. I think this could lead to empty records in the output files, and lots of tools struggle with that. I know it would be a bigger change, but I wonder if it would be better to output such reads to a "rejected" file as opposed to an "unmatched" pile.
Similarly, what happens if the reads are supposed to have UMIs, and have enough bases to cover the sample barcodes, but not the UMIs? Those will demux just fine and end up in output files, but with blank UMIs?
src/bin/commands/demux.rs
Outdated
| e | ||
| ) | ||
| }); | ||
| .unwrap_or((&EMPTY_BASES, &EMPTY_QUALS)); |
There was a problem hiding this comment.
I don't like doing this here because it will also eat any other errors coming out of extract_bases_and_quals. I think this will also (unexpectedly) lead to situations where a segment gets returned with 0 bases if it is defined as 8bp long and there are only 7bp available?
Should we perhaps change .extract_bases_and_quals() to extract the sub-set of bases that are available, and update the documentation to match?
The --skip-reasons options specifies the reason(s) to skip reads, with only TooFewBases currently supported.
nh13
force-pushed
the
feature/do-not-match-too-short-reads
branch
from
33dd5c4
to
6fe2ce9
Compare
Fixes: #27