Repository navigation
fix(vrs_map): stop normalizing reference-identical alleles into whole-sequence deletions - #114
Merged
Merged
Conversation
…-sequence deletions VRS normalization trims an unchanged sequence to an empty alternate and writes ReferenceLengthExpression(length=0), which describes deleting the whole sequence. Since 4d35a8c every p.=, c.= and g.= variant was mapped that way. Reference-identical alleles are now identified without normalizing, as they were when introduced in 9e430c2, which also matches the digests MaveDB already stores for them.
|
coverage: 0.0%. remained the same — fix/bencap/ref-identical-no-normalize into mavedb-dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The mapper has been writing every reference-identical variant (
p.=,c.=,g.=) as a deletion of the whole sequence. VRS normalization trims an unchanged sequence to an empty alternate and recordsReferenceLengthExpression(length=0), which means "replace the whole sequence with nothing". This identifies those alleles without normalizing them.Cause
_construct_vrs_allelebuilds a reference-identical allele as the full sequence withReferenceLengthExpression(length=L, repeatSubunitLength=L), which is correct. Since 4d35a8c it then passes the allele throughnormalize, which turns it intolength=0, sequence="", repeatSubunitLength=Lover the same location. 9e430c2, which added reference-identical support, only identified them.Found on production: mapping
urn:mavedb:00001316-a-1failed onRAF1:p.=, because MaveDB already holds the correct whole-sequence allele forNP_002871.1:p.=(ga4gh:VA.JRYlMMc2SCGXI6dQ1yGyONWLkL1wMa4d, from an older mapper) and the mapper now producedga4gh:VA.I6QVEH85J7-ud8ewJoUHsLubJ6CVxHoqfor the same HGVS. Where no older allele existed, the deletion form was stored silently: 15 alleles across 58 production score sets.Changes
vrs_map._construct_vrs_allele: reference-identical alleles getidentify_alleleonly, in both the pre-map and post-map branches.tests/test_vrs_map.py: offline regression test for both branches. It assertsnormalizeisn't called, the state length equals the location span, and the id matches MaveDB's stored allele forNP_002871.1:p.=.Testing
_construct_vrs_allele(["NP_002871.1:p.="], PROTEIN, None, pre_map=False)now returns the 0–648ReferenceLengthExpression(length=648)allele with idga4gh:VA.JRYlMMc2SCGXI6dQ1yGyONWLkL1wMa4d; before,I6QV…withlength=0.ruff checkandruff format --checkpass.tests/test_mavedb_data.pyhas the same 3respxfailures locally with and without this change.After merge this needs a release to
mavedb-mainand a production mapper image, then a data repair in MaveDB for the alleles already written.