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