Does a bad /asyncquery still require a job_id to be returned?

[edeutsch]

From Slack:

Jackson Callaghan (Exploring Agent, Service Provider)
2:20 PM
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?

New

Chris Bizon (SRI, Ranking Agent)
8:57 AM
@Eric Deutsch (Expander Agent)
please see Jackson's question above

Eric Deutsch (Expander Agent)
9:11 AM
I am thinking that we intended that a bad request would return a 400 or other HTTP code, at which point AsyncQueryResponse and job_id are not required. But I good point to bring up and clarify at the next meeting, thanks.

[tokebe]

Discussion in the architecture call shows agreement that an appropriate HTTP status code is sufficient, after which the response body doesn't have to conform to TRAPI.

[edeutsch]

Let's get some specific documentation in place to address this