John Snow <js...@redhat.com> writes:
> The QMP specification states:
>
>> NOTE: Some errors can occur before the Server is able to read the "id"
>> member, in these cases the "id" member will not be part of the error
>> response, even if provided by the client.
>
> I am assuming this case ONLY occurs for Parse errors:
>
> {'class': 'GenericError', 'desc': 'JSON parse error, expecting value'}
There are more "desc" possible, actually.
The JSON parser gets fed chunks of input, and calls a callback for every
full JSON value, and on parse error.
QMP's callback is handle_qmp_command(). Parameter @req is the parsed
JSON value, parameter @err is the (parse) error object, and exactly one
of them is non-null.
1. Parse error
If @err, we send an error response for it. It never has "id". See
qmp_error_response() caller monitor_qmp_dispatcher_co(). The possible
@err are:
$ grep error_setg qobject/json-*[ch]
qobject/json-parser.c: error_setg(&ctxt->err, "JSON parse error, %s",
message);
This is a syntax error.
Search for parse_error() to see the possible @message patterns.
qobject/json-streamer.c: error_setg(&err, "JSON parse error, stray
'%s'", input->str);
This is a lexical error.
qobject/json-streamer.c: error_setg(&err, "JSON token size limit
exceeded");
qobject/json-streamer.c: error_setg(&err, "JSON token count limit
exceeded");
qobject/json-streamer.c: error_setg(&err, "JSON nesting depth limit
exceeded");
These are (intentional) parser limits.
2. Successful parse
If @req, it's a successful parse.
If @req is not a JSON object, there is no "id". qmp_dispatch() reports
error_setg(&err, "QMP input must be a JSON object");
If @req is a JSON object, it has "id" exactly when the client supplied
one. The response mirrors @req's "id". See qmp_error_response() caller
qmp_dispatch().
> And I am assuming, in the context of a client that /always/ sets an
> 'id' for its execute statements, that this means that any error
> response we receive without an 'id' field *must* be associated with
> the most-recently-sent command.
Only if the client keeps no more than one command in flight.
Command responses get sent strictly in order (even parse errors), except
for commands executed out-of-band.
If the client sends N JSON values, and only then reads responses, and
there are no parse errors, then it'll get N responses. The i-th
response is for the i-th JSON value, except responses to OOB command may
"jump the queue".
With parse errors, it can get a different number of responses.
Questions?
