SVLEN conversion error about truvari HOT 3 CLOSED

Hello,

This type of error has been seen a few times. Recently, a pull request was proposed that would have changed the same line.

What's happening here is that pysam is handling the VCFs, and during its parsing it will use the header information to determine how to parse the fields (e.g. ##INFO=<ID=SVLEN,Number=1,Type=Integer,Description="Variant length"> instructs pysam to parse the SVLEN field as a single integer. I believe your VCF has a header line that instructs pysam to parse SVLEN as a single string (i.e. Type=String).

Therefore, this is a correct error that needs to be thrown. If SVLEN is a String and users put a value "FiveHunderedbp", that line would throw a ValueError: invalid literal for int() with base 10: 'FiveHunderedbp'

Have a great day,
~/Adam

from truvari.

I take your point but there are tools (in my case gridss that does this) and to reheater is a nuisance . How about:

try:
    size = abs(int(entry.info["SVLEN"]))
except (ValueError,TypeError):
    sys.exit("The SVLEN in the VCF INFO header is not valid")

as a compromise

from truvari.

I'll have to think about it, but I'll probably only go as far as trying to implement a more informative error and not the int type casting. VCFs can be a pain to deal with because so many of its format specifications read more like "should do" or "can do", instead of "must do". This allows tools a lot of flexibility in how they produce their VCFs.

Because one of Truvari's design goals is to handle as many VCFs as possible, I've - somewhat counterintuitively - chosen to be more strict with VCF handling. The VCF format specification (see https://samtools.github.io/hts-specs/VCFv4.2.pdf Section 3) doesn't explicitly "require" SVLEN to be an Integer, but in their own example they write the header as Type=Integer, and therefore I interpret it as a requirement.

I fully recognize that the int type casting is a very small hill to die on. But as a slippery-slope argument, opening the door to "Make this change for gridss", could allow more changes that are tailored per-tool. I fear this becoming an undue development burden on Truvari where - in this example - the responsibility should lie with gridds to properly define their output. So to sum this up in an overly cold way, blame gridss for the reheadering nuisance.

Hope you understand,
~/Adam

from truvari.