GATK upgrade from 4.0.11.0 to 4.1.0.0 seems to be breaking CalculateContamination

[asmoe4]

In our Mutect2 workflow, we run a pair of Normal/Tumor through CalculateContamination step, the output of which is used in FilterMutectCalls. Since upgrading to 4.1.0.0, CalculateContamination is breaking in cases where there're mismatched of N/T samples.

For e.g., 4.0.11.0 generates the following output:

level   contamination   error
whole_bam   0.5013841326835697  0.0055644124674135865

And 4.1.0.0 gives the following:

sample  contamination   error
Run06_Pair07_Tumor  1.0 0.03452380752462225

As a result of the above output files, the next step in our pipeline FilterMutectCall is failing (issue related to #5821)

[droazen]

@davidbenjamin or @LeeTL1220 could you comment?

[davidbenjamin]

@droazen We have a couple of merged PRs, #5873 and #5853, between which the error should not be thrown in the next minor release. However, this does not change the fact that users should never, ever, run the Mutect2 pipeline with an unmatched tumor-normal pair. When there is no matched normal, one should run it in tumor-only mode with a panel of normals.

[davidbenjamin]

I'm kind of glad that 4.1 exposed this because previously unmatched pairs were silently giving wildly-inflated contamination estimates.

[andrew-uzilov-s4]

This can occur in cases where there was a mixup with the samples, meaning the user intended to run a properly matched normal/tumor pair, but there is a provenance error. This is how @asmoe4 and myself hit this issue. So this is not the same use case as #5821, where they know there's a deliberate mismatch. While we're not expecting the contamination check to provide something sensible in this case, may I suggest that the tool provides a user-friendly message to help debug, rather than a stack traceback. This could happen to other people if they have an accidental mismatch.

[davidbenjamin]

@andrew-uzilov-s4 Your comment is very helpful. Thank you!