Out-of-order Msgpack responses from remote plugin cause channel to close

[ddickstein]

Neovim version (nvim -v)

0.7.0

Vim (not Nvim) behaves the same?

N/A

Operating system/version

CentOS 7.9

Terminal name/version

xfce4-terminal 0.8.7.4

$TERM environment variable

tmux-256color

Installation

system package manager

How to reproduce the issue

In a remote plugin in a language of your choosing, create a new RPC connection with Neovim. Then send the following:

1. [ 0, 1, "nvim_call_function", [ "rpcrequest", [ {channel id}, "rpc" ] ] ] (we receive: [ 0, 1, "rpc", [ ] ])
2. [ 0, 2, "nvim_call_function", [ "rpcrequest", [ {channel id}, "rpc" ] ] ] (we receive: [ 0, 2, "rpc", [ ] ])
3. [ 1, 1, nil, nil ]

Expected behavior

Neovim should continue being blocked until the remote plugin returns a response for request 2.

Actual behavior

Neovim closes the connection and the following error is logged in $NVIM_LOG_FILE:

call_set_error:615: RPC: ch {channel id} returned a response with an unknown request id. Ensure the client is properly synchronized

The Msgpack RPC spec says that responses can be given out of order, but it seems that Neovim requires responses to be given in reverse order of requests. The idea that responses should be given in this order is intuitive - operating like a call stack - but shouldn't be required per the spec.

[bfredl]

Rather, we should document that we deviate from the msgpack-rpc spec in this respect. In addition, properly supporting an async mixture of requests and notifications is going to require to deviate from the spec even more, not less.

[ddickstein]

In departing in this way from the Msgpack RPC spec, does Neovim guarantee that all messages, whether requests or notifications, will be processed in the order in which they are received?

[bfredl]

yes.

[justinmk]

#24061 mentions this in :help msgpack-rpc