Need to extract Edge support graphs from KP responses

[dkoslicki]

For this result:

The last bit of the log is: https://arax.ncats.io/test/?r=142477

2023-06-08T18:47:52.072024 INFO: Done transforming results to TRAPI 1.4 format (i.e., using support_graphs)
2023-06-08T18:47:52.072098 DEBUG: Storing resulting Message
2023-06-08T18:47:52.072120 DEBUG: Writing response record to MySQL
2023-06-08T18:47:52.086930 DEBUG: Writing response JSON to S3 bucket
2023-06-08T18:47:52.469040 DEBUG: Wrote /responses/142477.json in 0.20364048331975937 seconds
2023-06-08T18:47:52.470573 INFO: Result was stored with id 142477. It can be viewed at https://arax.ncats.io/?r=142477
2023-06-08T18:47:52.470676 INFO: Processing is complete and resulted in 100 results.
2023-06-08T18:47:52.470717 INFO: Processing is complete. Transmitting resulting Message back to client.

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?

[isbluis]

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.

[amykglen]

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)

[edeutsch]

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.

[amykglen]

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.

[amykglen]

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...