Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collections management web query error handling #81

Open
dskarls opened this issue Jan 21, 2022 · 0 comments
Open

Collections management web query error handling #81

dskarls opened this issue Jan 21, 2022 · 0 comments

Comments

@dskarls
Copy link
Contributor

dskarls commented Jan 21, 2022

As reported on the openkim matsci forum, the collections management utility doesn't check whether a web query call succeeds or not before trying to use its output. In this case, the user attempted to use the CM util to install a model. This caused a web query to be done here to retrieve the KIM API version compatible with the model. Rather than a version string, the result of the query was actually a JSON dictionary indicating a timeout had occurred on the server:

{"error": "127.0.0.1:27017: Errno 111 Connection refused, Timeout: 30s, Topology Description: <TopologyDescription id: 61df0e3746281eba22321a7d, topology_type: Single, servers: <ServerDescription ('127.0.0.1', 27017) server_type: Unknown, rtt: None, error=AutoReconnect('127.0.0.1:27017: Errno 111 Connection refused')>>"}

This then leads to trouble when the check_version_compatibility function is called, which attempts to do a bash test here to check if the KIM API major version of the item matches the major version of the KIM API installed on the system.

The real problem here is that the exit code of the web query process will be 0 because the query does indeed succeed, leading the associated check to proceed without throwing an error. However, a server-side error still results in unexpected data being returned. Currently, the query library on the openkim server is wrapped such that any error will result in a JSON dictionary being returned that contains a single key named 'error' that has a value equal to an error message. A simple check to put after the exit code check might be to see if the first few characters of the string returned by the query are {"error": and, if so, exit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant