Problem
mageckcount_search_variable_region never closes a variable region that runs to the end of the sequence it is given, so --umi auto cannot find a UMI that sits at the end of the read.
It sets var_start at the first column whose base composition looks random, then scans forward for the first column that does not, and assigns var_end there. If every remaining column is variable, the loop ends without assigning anything and var_end stays -1.
The common layout hits this exactly: a UMI immediately after the guide, with nothing following it. remainingseq_list is then the UMI and nothing else, every column is variable, and the search returns (0, -1).
Reproduce
An 8bp random UMI directly after a 20bp guide on read 1, 200 reads:
--umi auto -> "Search failed", exit non-zero
--umi firstpair --umi-start 0 --umi-end 8 -> 2000 rows, correct
Before #33 this was worse than a clean failure: (0, -1) was accepted as a successful second-read search — if umi_start_2 >= 0 or umi_end_2 >= 0 — so reads were sliced [0:-1] and umi_count.txt filled with plausible-looking rows built from unrelated read-2 sequence. #33 fixed the acceptance test, which turns the silent corruption into an honest failure. It does not make the search find the region.
Proposed change
When the scan reaches the end without finding a non-variable column, close the region at the end of the sequence rather than leaving var_end at -1. Guard the case where var_start is 0 and the whole sequence is variable, which is legitimate.
Worth adding at the same time: the caller logs the chosen window at info level, so a test can assert the window rather than only the row count.
Note
This is only reachable from --umi auto. --pairguide auto was disabled in #33 and is tracked separately in #32, which proposes a different search (library matching via mageckcount_trim5_auto) rather than this one.
Problem
mageckcount_search_variable_regionnever closes a variable region that runs to the end of the sequence it is given, so--umi autocannot find a UMI that sits at the end of the read.It sets
var_startat the first column whose base composition looks random, then scans forward for the first column that does not, and assignsvar_endthere. If every remaining column is variable, the loop ends without assigning anything andvar_endstays-1.The common layout hits this exactly: a UMI immediately after the guide, with nothing following it.
remainingseq_listis then the UMI and nothing else, every column is variable, and the search returns(0, -1).Reproduce
An 8bp random UMI directly after a 20bp guide on read 1, 200 reads:
Before #33 this was worse than a clean failure:
(0, -1)was accepted as a successful second-read search —if umi_start_2 >= 0 or umi_end_2 >= 0— so reads were sliced[0:-1]andumi_count.txtfilled with plausible-looking rows built from unrelated read-2 sequence. #33 fixed the acceptance test, which turns the silent corruption into an honest failure. It does not make the search find the region.Proposed change
When the scan reaches the end without finding a non-variable column, close the region at the end of the sequence rather than leaving
var_endat-1. Guard the case wherevar_startis 0 and the whole sequence is variable, which is legitimate.Worth adding at the same time: the caller logs the chosen window at
infolevel, so a test can assert the window rather than only the row count.Note
This is only reachable from
--umi auto.--pairguide autowas disabled in #33 and is tracked separately in #32, which proposes a different search (library matching viamageckcount_trim5_auto) rather than this one.