Variant page takes too long (~7 min) to load

[monicacecilia]

What I was doing: On the 'search bar,' in the home page or elsewhere, upon entering the name gana-1 (a worm gene), the autocomplete offers an option to go to a page describing a generic (not species-specific) variant.

The main problem:

• This request hangs for nearly 7 minutes before displaying results, and no errors are thrown while trying to access it https://beta.monarchinitiative.org/variant/SO:0000694. There were no connectivity problems on my end.

Other oddities to look into:

• When it finally loads, the page shows a Sequence Ontology term, not a worm-related or worm gene related variant.
• In the SO, the term SO:0000694 describes a generic SNP.
• There is a phenotype in worm with an identifier that also includes the numbers 0000694, WBPhenotype:0000694 (hermafrodite sterile), see https://beta.monarchinitiative.org/phenotype/WBPhenotype:0000694
• Is it possible that in the search for all information associated with the gana-1 gene, the identifier of a phenotype associated with the gene is being used to create a transitive association to results that, despite matching part of the ID for an associated phenotype, are not directly related to the gana-1 gene?
  • It is very, very confusing to see this in the results.
• In one of the times I visited the worm gene page on our site https://beta.monarchinitiative.org/gene/WormBase:WBGene00011095 - at first, I got the gana-1 information. A few minutes later, the panel on the right changed to the contents of the SO page I was calling earlier (see screenshot). Notice that the URL and header for the left panel describe a gene, while the right panel and the numbers in all the sections of the left panel are associated to the SO entry. It was very bizarre, though I was not [patient enough to be] able to reproduce it.

===============

[kshefchek]

I think this is an issue with the edge weighting. When we originally added edge weights, it was only after a user selected the gene radio button, since many genes have the same symbol (excluding casing). But over time something changed and we've included edge weights on all queries. Removing it seems to remove the SO class

https://api-dev.monarchinitiative.org/api/search/entity/autocomplete/gana-1?rows=10&start=0&highlight_class=hilite&boost_q=category%3Agenotype^-10&prefix=-OMIA&category=gene&category=variant&category=genotype&category=phenotype&category=disease&category=goterm&category=pathway&category=anatomy&category=substance&category=individual&category=publication&category=model&category=anatomical+entity

Some odd categories in here, goterm isn't a valid category, we should remove substance and individual too

Also, we've (maybe intentionally) removed the highlighting?

[deepakunni3]

https://beta.monarchinitiative.org/variant/SO:0000694 - request hangs for nearly 7 minutes before displaying results.

This is primarily because the term itself is a generic ontology term and in Monarch's Knowledge Graph we have thousands of associations to this term.

This is the summary of the number of associations where SO:0000694 is either a subject or an object of an association,

{
  "facet_pivot": {
    "association_type": [
      {
        "count": 98197,
        "field": "association_type",
        "value": "variant_phenotype"
      },
      {
        "count": 61618,
        "field": "association_type",
        "value": "variant_gene"
      },
      {
        "count": 33048,
        "field": "association_type",
        "value": "variant_disease"
      },
      {
        "count": 110,
        "field": "association_type",
        "value": "variant_genotype"
      },
      {
        "count": 108,
        "field": "association_type",
        "value": "case_variant"
      },
      {
        "count": 222,
        "field": "association_type",
        "value": "model_variant"
      },
      {
        "count": 116491,
        "field": "association_type",
        "value": "publication_variant"
      }
    ]
  }
}

The 7 minute hang is because there are three BioLink API queries that the UI fires:

1. To fetch the graph neighborhood for SO:0000694 (7 minutes)
2. Fetch association counts (instant)
3. Expand the CURIE to a URI (instant)

The first query is the longest because this query is actually going to SciGraph where it fetches all the nodes and edges at a depth of 1 (the default). Even at a depth of 1, there are 94812 nodes and 94814 edges returned by this query, which is considerably big.

Possible solutions:

• The UI restricts queries for graph neighborhood for ontology terms. But there is no way to know ahead of time if the CURIE you are querying is an ontology term.
• Add an option for pagination to SciGraph (similar to how it is in BioLink API where we can restrict the number of rows returned)

[monicacecilia]

@deepakunni3 if this type of query is inevitable, then the option for pagination sounds reasonable.

---

@kshefchek

• removing substance and individual sounds good. It should remove that entry from the list of autocomplete options, correct?

  Also, we've (maybe intentionally) removed the highlighting?

• What did the highlighting do?

[monicacecilia]

also, this seems to be an edge case, and not a mission critical fix for v1.0, so I am assigning to the next milestone.

[monicacecilia]

Updates from @kshefchek already took care of this. Yay! You get a :bowtie: !!