Open dkoslicki opened 1 year ago
Hi @dkoslicki . This should have been flagged by the validator as an incorrect/incomplete TRAPI response.
Specifically, there are several results with edge_bindings that contain references to support_graphs:
but the response message does not contain those graphs, as the relevant element is null:
The response needs to contain these graphs, otherwise they cannot be displayed.
ah, I think we probably need to update TRAPIQuerier to extract those missing aux graphs from KPs' responses (it currently ignores whatever aux graphs KPs might return)
So far only happening with Service provider but there may be more This is related to the whole "subclassing as a aux graph issue". they've started doing this when maybe they shouldn't Amy will tackle today? The solution is just for ARAX to pass through aux graphs from KPs.
so unfortunately I've been at the pet ER with my cat since early afternoon and haven't gotten to put much time into this 🙁
and it turns out this issue is a bit more complex than I thought: since edges/nodes used only in support graphs have no bindings to the QG (i.e., they don't fulfill any qnodes/qedges), that doesn't play well with our current system. I think if we want to preserve those support graphs we'll have to either create 'virtual' qnodes/qedges for such support nodes/edges to fulfill, or come up with some other non-insignificant workaround. currently our system just isn't set up to handle nodes/edges in the knowledge graph that have no bindings to the query graph.
I did, however, fix things so that we no longer generate invalid TRAPI in such cases: I added code (in master
) that deletes any biolink:support_graphs
attributes from Edges returned from KPs, since we're not extracting/preserving the actual aux graphs that those support graph attributes refer to (which is what was causing invalid TRAPI)
so, sorry to leave this one hanging. I do think service-provider was a bit premature in starting to encode subclassing in this way though - that change was delayed until at least post-June relay per the Architecture committee, and many teams (including us) were in favor of delaying it to after the September council meeting.
does this issue still warrant the high priority label? if KPs are generally still not using Edge support graphs, maybe it's low priority for us? or another way of looking at it: did "subclassing as an aux graph" ever happen?
as a summary of our current status here: we no longer produce errors when KPs include Edge support graphs in their responses, but we do ignore whatever is in those Edge support graphs...
For this result:
The last bit of the log is: https://arax.ncats.io/test/?r=142477
So everything seems kosher, but after this and before rendering the results, it says:
An error was encountered while contacting the server (TypeError: Cannot read properties of null (reading 'support0-MESH:D000069585-treats-MONDO:0001475-via_subclass'))
Is this a UI issue @isbluis or a validator issue @edeutsch , or something else perhaps?