cancervariants / cancervariants/variation-normalization

to_vrs returns valid results when hgvs position is greater than ref sequence length

Open
#449 2 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
Python
Stars
15
Forks
2
PR merge metrics
No merged PRs in 30d

Description

I'm not exactly sure what is happening here, but it seems wrong and is easily reproducible. It appears that when the `same as reference` hgvs syntax is used as shown below, that you can put a position in that is greater than the length of the sequence and it will still return a result with a state of `state: { type="LiteralSequenceExprssion",value=""}`. You can test it with the following expression...

`NM_000412.5:c.1930=`

The transcript `NM_000412.5` is `1947` residues long, but its CDS region is`19..1596`, so I'm assuming the `c.1929` is really be reference position `1929+(19-1)` or `1947` thus pointing to the last residue in the sequence. So, I would assume anything greater than c.1929 would fail. But as I write this out I'm thinking that `c.1929` should really fail since the coding sequence is really goes from the ref seq residue `19` through `1596`. This means the c. positions would go from `c.1 = 19` to `c.1577 = (1596 - 19)`. If this tracks then I would assume any c. position greater than `c.1577` should fail. Of course, if someone used the hgvs positional syntax to reference sequences further into the 3\`utr region like `c.*200` which would indicate an additional 200 residues into the 3\`utr region past the stop codon of the coding sequence.

In this transcript the last position that is valid using c. nomenclature would be `1947 base ref seq len - 1596 last cds position = 351` or `NM_000412.5:c.*351=`.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.