Error parsing SVLEN=. about truvari HOT 1 CLOSED

This is an interesting one. You've made a very reasonable fix that I'm considering adopting. However, there's two considerations.

First, if I were to actually incorporate this change, there would need to be more edge cases to check. For example, your proposed sub-if would only catch those VCFs in which the INFO Header for SVLEN defined Number=.. An equally valid definition is Number=1, such that the entry.info["SVLEN"] would not be in [list, tuple], so the last line size = abs(entry.info["SVLEN"]) would do the choking.

Second, I don't know for certain that SVLEN=. is a valid tag and perhaps Truvari really should be choking on these entries. The VCF Format specification doesn't explicitly disallow a null SVLEN, but it does have a clear definition of what the value should be. A flaw in the format is that there are a lot of 'should' specifications, but very few enforced 'musts'.
I've often found that VCFs reported by some tools take liberties with the format's flexibility. Instead of trying to account for every edge case, Truvari expects a stricter adherence to the specification. I would suggest a VCF cleaning/qc step before using Truvari. For example, the SVLEN tag could be stripped with bcftools annotate -x INFO/SVLEN, or a custom script could set it to the correct value.

from truvari.