Strand not taken into account inside GroupReadsByUmi

[SPPearce]

Hi fgbio,

I think I have found an issue with the GroupReadsByUmi code that I wasn't expecting.

I have a bam file containing 9 paired-end reads with the same start/end position, but 7 are on the forward strand and 2 are on the reverse strand:

The UMIs are all set to be the same, AAAAAA (see #1077 for the reason why!).
When I run GroupReadsByUmi I was expecting it to group the two strands separately; leading to two consensus reads, one on each strand.
However, instead I get (with "Edit" or "Adjacency") only one group and one consensus read (that corresponds to the forward strand, although that could be because it was the first read in the set).

If I set to a joint UMI like "AAAA-AAAA", Paired will correctly say these are the same.

It looks like the strand is not taken into account when marking the reads into a group, which will lead to sometimes combining both strands if there are reads at the same start/end with the same UMI. Probably a niche case for most library preps, but breaks everything when you set all the UMIs to be the same!

[SPPearce]

Attached is a sam file showing the issue (set as .txt for github to upload)
all_a.sam.txt

[znorgaard]

@tfenne can confirm, but I believe this was caught and resolved in #1074

Which means we're just waiting on a new release.

[tfenne]

That's right @znorgaard - although that PR goes into another feature branch, not into main.

@SPPearce if it works for you, you could try building off the feature/codec branch and seeing if that works for you? If that's a pain I could see about lifting that change on to main and getting a release out sooner.

[SPPearce]

Hmm, I've tried to build the feature/codec branch and I still get the same for the example sam file above.
java -jar target/scala-2.13/fgbio-2.5.22-61db498-SNAPSHOT.jar GroupReadsByUmi --input test.sam --output out.sam -f hist.txt --strategy "Identity" --edits 0

[SPPearce]

Ignore that, it seems to be working for me.

[SPPearce]

Just to update, the feature/codec branch is resolving this issue for me.
Do you have a timeline to release this?

[tfenne]

@SPPearce I'd like to get that branch merged into main next week, and a release cut. So probably fair to say within 2 weeks to be safe.