You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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.The text was updated successfully, but these errors were encountered: