`HgvsTools.is_intronic` misses intronic `r.` (RNA) variants

Empieza en src/ga4gh/vrs/utils/hgvs_tools.py, en HgvsTools.is_intronic, e inspecciona las comprobaciones relacionadas en src/ga4gh/vrs/extras/translator.py. Añade o ejecuta la matriz parametrizada sin red en tests/test_hgvs_tools.py, cubriendo los casos c., n., r., g., UTR e inciertos. La tarea está terminada cuando las entradas r. intrónicas se rechazan igual que c./n., mientras las clasificaciones existentes permanecen sin cambios.

Summary

HgvsTools.is_intronic gates on the outer sv.posedit.pos being a hgvs.location.BaseOffsetInterval. The hgvs library (2.0.0a0) emits BaseOffsetInterval for c. and n. variants but wraps r. (RNA) endpoints in a plain Interval, even though the inner positions are still BaseOffsetPositions carrying is_intronic=True. The outer-type gate therefore silently returns False for intronic r. inputs.

Both translator paths (AlleleTranslator._from_hgvs via extract_allele_values, and CnvTranslator._from_hgvs) rely on this check to reject intronic inputs before building a SequenceLocation. When the check is bypassed, downstream code accesses pos.start.base / pos.end.base and drops the intron offset, producing a SequenceLocation whose coordinates point at the exon-boundary position in the mature transcript rather than signaling an unrepresentable variant.

Per VRS 2.0 — Implied Sequence Coordinates, offset positions representing sequence not found on the SequenceReference cannot be encoded as VRS start/end values at all. Intronic HGVS inputs should therefore be rejected — which is what is_intronic is meant to do, and does correctly for c./n. but not r..

Reproducer

from ga4gh.vrs.utils.hgvs_tools import HgvsTools
from ga4gh.vrs.dataproxy import SeqRepoRESTDataProxy

dp = SeqRepoRESTDataProxy(
    base_url="http://localhost:5000/seqrepo", disable_healthcheck=True
)
ht = HgvsTools(dp)

for expr in [
    "NM_000001.1:c.100+5A>T",  # c. intronic — correctly detected
    "NR_000001.1:n.100+5A>T",  # n. intronic — correctly detected
    "NM_000001.1:r.100+5a>u",  # r. intronic — silently missed
]:
    sv = ht.parse(expr)
    print(expr, "→ is_intronic:", ht.is_intronic(sv))

Output (current):

NM_000001.1:c.100+5A>T → is_intronic: True
NR_000001.1:n.100+5A>T → is_intronic: True
NM_000001.1:r.100+5a>u → is_intronic: False    ← should be True

Real-world r. examples from ClinVar

The following r. expressions come from ClinVar.
All four parse cleanly under hgvs 2.0.0a0
and exhibit the same Interval + BaseOffsetPosition shape that motivates
this issue. They are all exonic (offset=0), so they are not affected
by the bug — they are correctly classified as non-intronic by both the
current and proposed is_intronic implementations. They are listed here as
representative real-world r. inputs to pin in future regression tests.

Expression	Outer pos	Inner type	offset	Intronic?
NR_001566.1:r.398_399del	Interval	BaseOffsetPosition	0 / 0	No
NR_001566.1:r.245del	Interval	BaseOffsetPosition	0 / 0	No
NM_001374385.1:r.2843_2931del	Interval	BaseOffsetPosition	0 / 0	No
NM_001323289.2:r.2632c>a	Interval	BaseOffsetPosition	0 / 0	No

These examples confirm two relevant properties of the parser:

1. The Interval + BaseOffsetPosition wrapping is consistent across r.
   inputs regardless of edit type (del, >) or accession namespace
   (NM_* or NR_*). The proposed per-endpoint isinstance check will
   classify all four as non-intronic and allow them through.
2. The bug surfaces only when a hypothetical intronic counterpart
   (e.g. NM_001374385.1:r.2843+1_2931del) is encountered. No such example
   exists in the ClinVar set we inspected, which may be why the gap has not
   been reported before.

If someone has a real intronic r. example from a curated source, it
should be added to the regression test matrix below.

Why the outer gate is wrong

Walking the parser's output for each prefix:

Input	Outer sv.posedit.pos	Inner .start / .end	is_intronic(sv) should be
g.100_200del	Interval	SimplePosition	False (g. has no intronic concept)
c.100+5A>T	BaseOffsetInterval	BaseOffsetPosition(offset=5)	True
c.100A>T	BaseOffsetInterval	BaseOffsetPosition(offset=0)	False
n.100+5A>T	BaseOffsetInterval	BaseOffsetPosition(offset=5)	True
r.100+5a>u	Interval	BaseOffsetPosition(offset=5)	True (currently returns False)
g.(A_B)_(C_D)del	Interval(uncertain=True)	nested Interval of SimplePosition	False (parser forbids uncertain on c./n./r., so no intronic-uncertain combination is reachable)

The r. row is the only case where the outer-gate check disagrees with the correct answer.

Proposed fix

Replace the container-type gate with per-endpoint isinstance checks on BaseOffsetPosition:

def is_intronic(self, sv: HgvsSequenceVariant) -> bool:
    """Check if the given SequenceVariant is intronic.

    Tests each endpoint directly rather than gating on the outer container
    type. hgvs 2.0.0a0 wraps the BaseOffsetPosition endpoints of ``r.`` (RNA)
    variants in a plain ``Interval`` (not ``BaseOffsetInterval``); a
    container-only gate silently misses ``r.`` intronic forms like
    ``r.100+5a>u``.

    Returns:
        bool: True if either endpoint is a :class:`BaseOffsetPosition` with
        a non-zero (or ``None``) offset.
    """
    start = sv.posedit.pos.start
    end = sv.posedit.pos.end
    return (
        isinstance(start, hgvs.location.BaseOffsetPosition) and start.is_intronic
    ) or (
        isinstance(end, hgvs.location.BaseOffsetPosition) and end.is_intronic
    )

Behavior preservation across existing cases

• g.* inputs: SimplePosition endpoints fail both isinstance checks → False (unchanged)
• c./n. exonic: BaseOffsetPosition(offset=0) → isinstance True, is_intronic False → False (unchanged)
• c./n. intronic (either side): is_intronic True on at least one endpoint → True (unchanged)
• UTR forms like c.-10 / c.*10: BaseOffsetPosition(offset=0) → False (unchanged)
• Uncertain ranges on g.: inner endpoints are nested Interval, not BaseOffsetPosition → False (unchanged; correct since g. has no intronic concept)
• r. intronic: now returns True — this is the fix.

Callsites require no changes

Both existing guards — src/ga4gh/vrs/utils/hgvs_tools.py:282-284 and src/ga4gh/vrs/extras/translator.py:491-493 — consume only the boolean return and raise ValueError("Intronic HGVS variants are not supported") when True. Behavior for previously-rejected inputs is unchanged.

Test case

Add a network-free parametrized test to tests/test_hgvs_tools.py. No data-proxy or cassette needed — the check operates purely on the parsed hgvs object. Suggested parametrization covers every row of the matrix above.

import hgvs.parser
import pytest

from ga4gh.vrs.utils.hgvs_tools import HgvsTools


@pytest.fixture(scope="module")
def hgvs_tools():
    # is_intronic doesn't touch the data_proxy; pass None to avoid wiring
    # up seqrepo/UTA for a pure shape test.
    return HgvsTools(data_proxy=None)


class TestIsIntronic:
    """Pins the behavior of :meth:`HgvsTools.is_intronic` across every
    HGVS prefix and endpoint-shape combination the hgvs parser can produce.
    """

    @pytest.mark.parametrize(
        ("hgvs_expr", "expected"),
        [
            # Genomic: no intronic concept
            ("NC_000001.11:g.100_200del", False),
            # Coding: exonic, 5' UTR, 3' UTR
            ("NM_000001.1:c.100A>T", False),
            ("NM_000001.1:c.-10A>T", False),
            ("NM_000001.1:c.*10A>T", False),
            # Coding: intronic
            ("NM_000001.1:c.100+5A>T", True),
            ("NM_000001.1:c.100-3A>T", True),
            # Coding: mixed intronic / exonic endpoints
            ("NM_000001.1:c.100+5_200del", True),
            ("NM_000001.1:c.100_200+5del", True),
            # Non-coding transcript
            ("NR_000001.1:n.100A>T", False),
            ("NR_000001.1:n.100+5A>T", True),
            # RNA — the gap this issue addresses
            ("NM_000001.1:r.100a>u", False),
            ("NM_000001.1:r.100+5a>u", True),
            # ClinVar-derived real-world r. examples (all exonic; confirm
            # the proposed per-endpoint check correctly classifies them)
            ("NR_001566.1:r.398_399del", False),
            ("NR_001566.1:r.245del", False),
            ("NM_001374385.1:r.2843_2931del", False),
            ("NM_001323289.2:r.2632c>a", False),
            # Genomic uncertain range (structural form #609 uses)
            ("NC_000001.11:g.(100_200)_(300_400)del", False),
        ],
    )
    def test_is_intronic_matrix(self, hgvs_tools, hgvs_expr, expected):
        sv = hgvs_tools.parse(hgvs_expr)
        assert hgvs_tools.is_intronic(sv) is expected

Note: HgvsTools.__init__ currently opens a UTA connection unconditionally. For this test to be truly network-free, the fixture may need HgvsTools.is_intronic to tolerate data_proxy=None at construction — if that's not already the case, either lazy-init the UTA connection or move is_intronic to a free-function helper that doesn't take self. Either shape is a small refactor, scope-adjacent to this issue.

Scope and impact

• Pre-existing gap; not introduced by or related to issue #609.
• Impact for consumers: any r.100+5a>u-style intronic RNA input that made it through AlleleTranslator._from_hgvs on the current v3 code would have produced a SequenceLocation with coordinates that don't reflect the intronic offset (off by the offset's magnitude). After the fix, the same input raises ValueError("Intronic HGVS variants are not supported"), matching the c./n. behavior.
• No r. test cases exist in the current test suite, consistent with r. being a less commonly used HGVS prefix for vrs-python's consumers. Opening this issue separately (rather than bundling into the #609 PR) keeps the scope clean and lets a maintainer decide whether r. support is in-scope to harden or out-of-scope to reject upstream.

Alternative: reject r. outright

If r. is deemed out of scope for vrs-python, a simpler fix is to reject all r. inputs (the way p. protein inputs are rejected at src/ga4gh/vrs/utils/hgvs_tools.py:397-399 on the reverse path). That is a stricter but less surgical change and should be decided separately by the project maintainers.