Should we blocklist failing KPs (e.g. SPOKE) from ARAX?
Perhaps this could be implemented as a simple module-scope variable like:
BLACKLISTED_KPS = ('infores:spoke', 'infores:foo', )
near the top of the SmartAPI.py module? Then it is compiled into the module bytecode and not loaded from a file at query-time. I am not worried about the length of this variable becoming "unwieldy", given the number of TRAPI-compliant KPs that are currently in the Smart API registry.
Suggested module-scope variable initialization should work, but I'm wondering whether it's necessary now. With recent changes in the issue2563 branch
Even if SPOKE remains in meta_map from older cache content, it won’t be used unless it returns 200 during the latest refresh and appears in valid_kps. This prevents querying KPs whose /meta_knowledge_graph is currently down, eliminating the class of runtime failures.
And also leaves room in case SPOKE endpoint comes back to live in the future if someone would decide to maintain it and bring back , we will automatically catch the endpoint on kp refresh and start using it again.
@saramsey I think your suggestion to black list SPOKE completely is wise, because of the inconsistency in results we get, if we leave it for consideration (if it gets back online).
Sometimes SPOKE is unreachable, and sometimes it's reachable on the arax.ncats.io/test endpoint:
So we can't rely on SPOKE since it's unstable and might create problems for our results in UI, because replication of the results is out of our control.