Closed lynnpais closed 7 months ago
Correction: it does come up in a de novo search only if translocations are selected as an annotation. However, if you select translocation AND HOXA13 in the location, it gets filtered out.
I was able to find the links for this, but in the future I really need you to provide links to everything related to your bug, including follow up findings like this
Gene and translocation - no results https://seqr.broadinstitute.org/variant_search/results/7e809d8231adbdd2610747b04d458f9c?page=1&sort=xpos
translocation only - result in the gene https://seqr.broadinstitute.org/variant_search/results/563cf21df04915173f3090fe76f22e03?page=1&sort=xpos
So gene search for SVs does not return variants in genes whose only predicted consequence is "NEAREST_TSS". This is similar to how for SNPs gene search does not return upstream/ downstream variants. If we want we can change this behavior for future rounds of SV loading, but it would be changing intentional behavior. Transitioning this issue from bug to feature request, as the application is behaving as intended
Worth considering this when implementing https://github.com/broadinstitute/seqr/issues/2634 - for adding genes with no predicted consequence do we want them to display but not search the way NEAREST_TSS does now, or do we want to change this so all displayed genes are searchable
Discussed at latest analysis meeting that we do want variants annotated in genes as "Nearest TSS" to by default come back when searching in a given gene(s), and add "Nearest TSS" as an option in the SV annotation filter to explicitly include/ exclude.
This will be added the next time we do SV loading
@hanars I believe you were right on with your guess on this!
Our new logic, preserving NEAREST_TSS
in the major_consequence_id
field of the SV sorted_gene_consequences
.
Our old logic, filtering the genes with NEAREST_TSS
as the major consequence.
I went to validate on the hail-search service though, and ran into:
So https://github.com/broadinstitute/seqr/issues/3729 is needed.
okay so probably this will be fixed when the new backend goes live without any additional dev work!
So it looks like this variant is no longer annotated in the gene from the original ticket, and in fact doing a seqr search for the variant indicates its fully absent from seqr, meaning this variant dropped out completely in a more recent round of loading. I would like to validate that search is working as expected though - @lynnpais do you have any examples of SVs with NEAREST_TSS annotations that we could use to validate that search is working as expected in the new backend?
Here's a super permissive search I used to return SVs with the Nearest TSS annotation - https://seqr.broadinstitute.org/variant_search/results/a6b43a5ff7e42aca4cca4689ae8b5573?page=1&sort=xpos
okay it appears that searching for a gene does not return variants with NEAREST_TSS in the hail backend, so it looks like there is still feature work to do here
this is now fixed
Describe the bug Alba first called a translocation involving HOXA13. I searched and tagged it in seqr - https://seqr.broadinstitute.org/project/R0384_rare_genomes_project_gen/saved_variants/variant/SV0105074_5152804697_f026893_r
However, if I search now, for ANY SV variants in ANY affected, using HOXA13 as location, the translocation does not show up. But another low quality one does - https://seqr.broadinstitute.org/variant_search/results/b419fbb7ae6465d3b5ef617612eb7eae?page=1&sort=pathogenicity
I tried multiple other ways, but this specific HOXA13 translation is no longer coming up.
Link to page(s) where bug is occurring https://seqr.broadinstitute.org/variant_search/results/b419fbb7ae6465d3b5ef617612eb7eae?page=1&sort=pathogenicity
Scope of the bug Unsure
Screenshots Variant of interest, not coming up in a targeted or de novo search