Tendermint version (use tendermint version or git rev-parse --verify HEAD if installed from source):

0.25.0-0c9c3292

ABCI app (name for built-in, URL for self-written if it's publicly available):

kvstore

Environment:

• OS (e.g. from /etc/os-release):

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"

• Install tools:
• Others:

What happened:

The responses to "subscribe" over websocket are not as expected.

I believe that they are not in conformance with the RPC 2.0 spec. (I could be wrong about that.)

When the following "subscribe" message is sent over the websocket:

{"jsonrpc":"2.0","method":"subscribe","id":"1","params":["tm.event = 'NewBlock'"]} I get this response:

I get the following response:

{
"jsonrpc": "2.0",
"id": "1",
"result": {}
}

This is as expected, indicating that the message was received and processed without error. In the above, the "id" value is 1, indicating this is the first request sent. (I send it immediately after connecting the socket.)

Subsequently, whenever a new block is created, I get a message like this:

{"jsonrpc":"2.0","id":"1#event","result":{"query":"tm.event = 'NewBlock'","data":{"type":"tendermint/event/NewBlock","value":{"block": ..... (block contents deleted)

I believe this is NOT in accordance with the JSON RPC 2.0 spec. The id value is set to "1#event', which chokes the javascript RPC library I'm using. (https://github.com/jershell/simple-jsonrpc-js)

I think I get the idea behind this - sending the events responding to the subscription request with an id value that can be correlated back to the original request. But I don't think this is conformant. The spec says the ID value has to be identical to the request, and that a notification should not contain an ID value.

I was able to work around this by hacking the siimple-jsonrpc-js code to look for responses with id's ending in #event, and convert them into notifications.

Maybe this is how RPC 2.0 is supposed to work? If so, I'm not seeing that in the spec, and the library I'm using doesn't recognize it.

I do see a related bug request #1099

What you expected to happen:

The events resulting from a subscription request should be sent as NOTIFICATIONs.

Have you tried the latest version: yes/no

No. Latest now appears to be 0.26.4, and I see in the comments that a fix was made to accept integer IDs (I also ran into that one, so that's great.) I will try to download latest and test against it, but I don't see anything in change log that indicates this has been fixed.

How to reproduce it (as minimally and precisely as possible):

Send any valid subscribe message over websocket and then dump out the responses that come back.

Logs (paste a small part showing an error (< 10 lines) or link a pastebin, gist, etc. containing more of the log file):

See above.

Config (you can paste only the changes you've made):

node command runtime flags:

/dump_consensus_state output for consensus bugs

Anything else we need to know: