Modified Fragment creation for mutect2 to not fail for supplementary reads

[KevinCLydon]

Modified the fragment creation code to not throw an exception in the case that there are more than 2 reads supporting a fragment and they are all supplementary, secondary, and/or duplicates. Instead, it will just pick one of those reads to use.

[davidbenjamin]

Looks good!

[davidbenjamin]

Is this new import used?

[KevinCLydon]

Oops, I forgot to remove that before committing. I'll take that out

[pieterlukasse]

hi @KevinCLydon, @davidbenjamin , thanks for this fix. I am preparing a custom version of 4.1.4.1 with just this patch on top of it. One question I had is: is this a safe patch to have on its own, or does it need to go in tandem with any other patch to form a proper release (and not break anything else)? Given this fix is now ~7 months old, I'm hoping insiders can maybe tell me if any other patch ended up being needed after this one, either to deal with the same issue, or to deal with any new issues introduced by it (if any).

[fleharty]

@pieterlukasse I don't know if this is an appropriate solution.
If you are willing to filter supllementary reads, you can use this argument and it might do what you need.
--read-filter NotSupplementaryAlignmentReadFilter

[pieterlukasse]

thanks @fleharty . I can confirm that using --read-filter NotSupplementaryAlignmentReadFilter in my case does result in a successful run. Thanks for letting me know about this alternative. 👍

[pieterlukasse]

@fleharty I looked up other tickets for this extra --read-filter and found this #6230 (comment) . This comment and following comments lead me to think there might be an issue with this --read-filter that was only solved in 4.1.5.0? Or has --read-filter issue also been solved in 4.1.4.1?

[pieterlukasse]

I think I understand it now: #6240 did fix the --read-filter NotSupplementaryAlignmentReadFilter issue and this fix got into 4.1.4.1. Not using the --read-filter however, does cause another issue in 4.1.4.1 which this PR (6327) solved and is in 4.1.5.0 and later. Correct?

[davidbenjamin]

@pieterlukasse Almost correct: #6240 partially solved the issue but left an edge case that #6327 fixed. The 4.1.5.0 release is the only one guaranteed to work, though 4.1.4.1 works for the great majority of samples.