Repository navigation
Lookup query has mystery complaints about aux graphs #2878
Description
For this query:
{
"message": {
"query_graph": {
"nodes": {
"sn": {
"ids": [
"MONDO:0005044"
],
"categories": [
"biolink:Disease"
]
},
"on": {
"categories": [
"biolink:NamedThing"
]
}
},
"edges": {
"b7cab2b0": {
"subject": "sn",
"object": "on",
"predicates": [
"biolink:related_to"
],
"knowledge_type": "lookup"
}
}
}
},
"validate": false,
"callback": "https://ars.ci.transltr.io/ars/api/messages/6a8dba4c-34f4-4f5f-b035-cdd89d346b27",
"submitter": "Shepherd",
"remote_address": "52.4.10.150"
}
This was the query that confounded our testing: looking for all neighbors of hypertension. This errored out. On the ARAX UI (arax.ncats.io), I notice that while the lookup is rather quick, there are a ton of complaints about edges having aux graphs which have edges that aren't in the KG. Willow couldn't replicated directly with retriever, so it appears to be an ARAX problem.
@edeutsch and @isbluis , wouldn't such messages only appear when validation is run? I wouldn't expect validation to run here. It might not ever finish, hence leading to the long running time and/or erroring out
Activity
dkoslicki commentedon Sep 1, 2026
The mystery deepens: specifying this to be
Diseaseinstead ofNamedThingresults in a similar (but more manageable) issue, but did not cause an issue when specifying this to beDrug, which has more results.Compare:
https://arax.ncats.io/?r=527841
vs.
https://arax.ncats.io/?r=527842
So this does not (?) appear to be a dehydrate/rehydrate thing; it's nowhere near the 100K limit for dehydration. @tokebe, any ideas?
dkoslicki commentedon Sep 1, 2026
Somehow, we find unbound edges, but @tokebe reports not seeing this in retriever
In 5 thousandths of a second, we go from no unbound to a bunch of unbound edges
tokebe commentedon Sep 1, 2026
For context, I used the trapi-testing-tools to run the queries against retriever. Its integrity checks show no orphan aux graphs, no orphan edges, no aux graphs binding non-existent edges