Re: QMP and the 'id' parameter

[Markus Armbruster <armbru@redhat.com>]

John Snow <jsnow@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?