phase 1: changes to async-job-checking and asyncquery endpoints

[colleenXu]

Basic summary:

• The TRAPI PR describes /async_query_status/{job_id} endpoint and response format AsyncQueryStatusResponse
  • we'll probably update the existing check_query_status endpoint...another option is to make a new endpoint?
  • not sure if we're planning to "stream" logs / progress / queue-position using this endpoint...
• This PR ALSO describes an update to /asyncquery response format...they now require the job_id (look up AsyncQueryResponse in the linked PR)
• Note that updating the SmartAPI yamls (another issue) will be needed to advertise the /async_query_status/{job_id} endpoint since it's new

I'll leave it to others like @tokebe or @newgene to add details/requirements as needed.

From bullet 5 of changelog:

Add /async_query_status/{job_id} endpoint https://github.com/NCATSTranslator/ReasonerAPI/pull/395/files

• timing: phase 1. Jackson says this is easy + quick to knock out.
• priority: medium? get it done and move on?
• responsible dev: Jackson

[colleenXu]

Noting some info from @tokebe on Slack, regarding async-job's response "status" field:

The current complete set of possibilities are completed, failed, delayed, active, waiting, paused, stuck or null because statuses come from Bull, however after TRAPI 1.4 we'll have to change these to one of Queued, Running, Completed, Failed

Just a note, you shouldn't ever see delayed, paused, stuck, or null with the current code

[colleenXu]

Update notes: opening post was last updated 4/4 evening

• TRAPI 1.4 may still change. When those changes happen, they should be on this branch and documented in this branch's changelog

[colleenXu]

@tokebe's question and its answer:

Question:

RE: TRAPI 1.4 Asyncquery status.
Given the spec of AsyncQueryResponse, it's implied that we could return a non-Accepted status, such as in cases of an invalid query. However, job_id is non-nullable. In the event of an invalid query, for instance, something that would fit QueryNotTraversable, is it acceptable to return that status and a description, but not an ID? Or should a junk ID be returned, such as job_id: REJECTED?

Answer to implement: we intended that a bad request would return a 400 or other HTTP code, at which point AsyncQueryResponse and job_id are not required....

References:

• Jackson's question in Translator internal Slack
• tentative reply, which was confirmed during 4/11 architecture call
• TRAPI repo issue for this: Does a bad /asyncquery still require a job_id to be returned? NCATSTranslator/ReasonerAPI#424

[tokebe]

No new code required to address the current answer to my question, unless something changes, the only thing left is updating our own SmartAPI.

[colleenXu]

Note that biothings.io/explorer runs async queries in its "try it" page by using the ITRB prod instance (this issue).

If we push these updates up to ITRB prod, we may need to check that this webpage still works..

[colleenXu]

Going to close this because all instances are deployed with the code related to this issue.

EDIT: I'd like @tokebe to confirm that the requirements of this issue have been fulfilled and if so, close this issue...

[tokebe]

Requirements fulfilled, related follow-up work can be tracked under #671