I'm testing the BioPortal Rails application against Ruby 3.0.6, and the staging version of the BioPortal REST API, which is currently running on the AllegroGraph database. In my local dev environment, I'm seeing intermittent failures from two of the API calls inside of the refresh_cache method:
def refresh_cache
Spawnling.new do
LinkedData::Client::Models::Ontology.all
LinkedData::Client::Models::OntologySubmission.all
LinkedData::Client::Models::User.all
exit
end
end
The call to fetch all OntologySubmission objects results in an empty array, or a Faraday::TimeoutError. The call to fetch all users sometimes returns user data, and sometimes results in the same Faraday::TimeoutError.
The responses of these calls are never examined/logged, so they essentially appear to be silent failures. @mdorf is looking into why the /submissions endpoint returns an emtpy array from an AllegroGraph database (see https://github.com/ncbo/ontologies_api/issues/117).
We may want to consider - at a minimum - logging error responses from these calls, so that we're at least aware when they occur.
I'm testing the BioPortal Rails application against Ruby 3.0.6, and the staging version of the BioPortal REST API, which is currently running on the AllegroGraph database. In my local dev environment, I'm seeing intermittent failures from two of the API calls inside of the refresh_cache method:
The call to fetch all OntologySubmission objects results in an empty array, or a Faraday::TimeoutError. The call to fetch all users sometimes returns user data, and sometimes results in the same Faraday::TimeoutError.
The responses of these calls are never examined/logged, so they essentially appear to be silent failures. @mdorf is looking into why the /submissions endpoint returns an emtpy array from an AllegroGraph database (see https://github.com/ncbo/ontologies_api/issues/117).
We may want to consider - at a minimum - logging error responses from these calls, so that we're at least aware when they occur.