Results being removed by ARS for pathfinder queries during post processing

[MarkDWilliams]

Not sure how this is happening yet, but I suspect something to do with the unusual structure of Pathfinder results fields. In the example below, the individual ARA responses have populated results field, but once they get put into merged_version, results becomes an empty list.

https://ars.ci.transltr.io/ars/api/messages/f1aaca9f-4f5d-495c-83f4-610af37afc35?trace=y

[MarkDWilliams]

Haven't finished hunting this down, but suspect that the issue is that if any part of the response contains a node that is on the blocklist, we remove all references to that node. Given that pathfinder queries only have one "result", a bad node anywhere would remove the only result that we have, leaving us with an empty list.

[MarkDWilliams]

The plot thickens. The query is pathfinder between TNF and Cancer. I did not realize that Cancer is on the blocklist. So, basically everything is going to touch that node.

[MarkDWilliams]

Given that every supporting edge would have included a blocked node, the one result would have no evidence after those are removed, and thus the result itself would be removed. So, in this context, I believe that the ARS is functioning as intended. The larger issue seems to be the dissonance between the UI/NameResolver blocklist and the one the ARS is applying. It should not be possible to form a query which has, as a pinned node, a CURIE which is blocked by the ARS. Alternately, we could consider exempting any CURIEs specifically encoded in a query graph from removal due to blocklist. If the user wants to ask that query, who am I to tell them no?

[MarkDWilliams]

Potential fixes for this issue on hold pending a discussion with UI about whether we should allow these types of queries in the first place.

[MarkDWilliams]

But wait, there's more. If downstream tools do subclassing (e.g. make paths to "Bone Cancer" instead of "Cancer"), those results/support graphs will not be removed, leaving us with a non-zero amount of results which UI is able to display. I still think the larger issue is whether the query should be allowed in the first place. The partial removal in this case is, in my opinion, the blocklist functionality working as designed, but the whole situation is kind of an odd case.

https://ui.transltr.io/results?l=Cancer&i=MONDO:0004992&t=0&r=0&q=5b61e9c2-ac1c-46de-bd3c-04ec7bf533f6