Re: QMP and the 'id' parameter

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Nov 10, 2020 at 07:22:26AM +0100, Markus Armbruster wrote:
> 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.

With out of band commands, how much runs in the background ? Is the
JSON parsing still in the foreground, such that we can expect that
even for OOB commands, a error response without a "id" is still
received strictly in order.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|