Skip to content

rpc/lib/client & server: try to conform to JSON-RPC 2.0 spec#3858

Closed
melekes wants to merge 14 commits intomasterfrom
anton/3853-rpc-ids
Closed

rpc/lib/client & server: try to conform to JSON-RPC 2.0 spec#3858
melekes wants to merge 14 commits intomasterfrom
anton/3853-rpc-ids

Conversation

@melekes
Copy link
Contributor

@melekes melekes commented Jul 31, 2019

https://www.jsonrpc.org/specification

What is done in this PR:

  • JSONRPCClient: validate that Response.ID matches Request.ID
    I wanted to do the same for the WSClient, but since we're sending events as responses, not notifications, checking IDs would require storing them in memory indefinitely (and we won't be able to remove them upon client unsubscribing because ID is different then).

  • Request.ID is now optional. Notification is a Request without an ID. Previously "" or 0 were considered as notifications

  • Remove #event suffix from ID from an event response (partially fixes Responses to "subscribe" sent over WebSocket don't conform to RPC 2.0 specification #2949) ID must be either string, int or null AND must be equal to request's ID. Now, because we've implemented events as responses, WS clients are tripping when they see Response.ID("0#event") != Request.ID("0"). Implementing events as requests would require a lot of time (~ 2 days to completely rewrite WS client and server)

  • generate unique ID for each request

  • switch to integer IDs instead of "json-client-XYZ"
    id=0 method=/subscribe
    id=0 result=...
    id=1 method=/abci_query
    id=1 result=...

TODO:


  • Referenced an issue explaining the need for the change
  • Updated all relevant documentation in docs
  • Updated all code comments where relevant
  • Wrote tests
  • Updated CHANGELOG_PENDING.md

@melekes melekes changed the title rpc: generate an unique ID for each request rpc/lib/client & server: conform to JSON-RPC 2.0 spec Aug 1, 2019
@melekes melekes self-assigned this Aug 1, 2019
@codecov-io
Copy link

codecov-io commented Aug 1, 2019

Codecov Report

❗ No coverage uploaded for pull request base (master@f9cce28). Click here to learn what that means.
The diff coverage is 41.62%.

@@            Coverage Diff            @@
##             master    #3858   +/-   ##
=========================================
  Coverage          ?   65.92%           
=========================================
  Files             ?      240           
  Lines             ?    20297           
  Branches          ?        0           
=========================================
  Hits              ?    13381           
  Misses            ?     5861           
  Partials          ?     1055
Impacted Files Coverage Δ
rpc/core/events.go 0% <0%> (ø)
tools/tm-bench/transacter.go 8.49% <0%> (ø)
rpc/lib/server/http_server.go 63.36% <0%> (ø)
rpc/lib/client/http_uri_client.go 0% <0%> (ø)
rpc/lib/client/http_json_client.go 9.64% <21.56%> (ø)
rpc/lib/server/ws_handler.go 35.32% <35.32%> (ø)
rpc/lib/server/http_uri_handler.go 42.42% <42.42%> (ø)
rpc/lib/client/encode.go 47.82% <47.82%> (ø)
rpc/lib/client/decode.go 5.08% <5.08%> (ø)
rpc/lib/client/ws_client.go 58.77% <60%> (ø)
... and 2 more

@melekes
Copy link
Contributor Author

melekes commented Aug 1, 2019

send events (resulting from /subscribe) as requests+notifications (not responses)

this will require a lot of work. probably not worth it

cdc: cdc,
Upgrader: websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool {
// TODO ???
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

???

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default behaviour would be relevant to browser-based clients, afaik. I suppose having a pass-through is a workaround for allowing for more complex security schemes, shifting the burden of AuthN/AuthZ outside the Tendermint RPC.

I can't think of other uses right now that would warrant a TODO though. The real backstory of this TODO shall remain shrouded in mystery 👻

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gold! Saved this comment for future generations 😄

@melekes melekes added the T:breaking Type: Breaking Change label Aug 1, 2019
@melekes melekes marked this pull request as ready for review August 1, 2019 14:09
@melekes melekes requested review from ebuchman and xla as code owners August 1, 2019 14:09
@melekes melekes changed the title rpc/lib/client & server: conform to JSON-RPC 2.0 spec rpc/lib/client & server: try to conform to JSON-RPC 2.0 spec Aug 1, 2019
it will be closed automatically
@melekes melekes added the R:major PR contains breaking changes that have to wait till a major release is made to be merged label Aug 5, 2019
@tac0turtle
Copy link
Contributor

send events (resulting from /subscribe) as requests+notifications (not responses)

this will require a lot of work. probably not worth it

I do believe this is worth it, to bring us within the spec and what the wider community is using and used to. Do you think we could have it for 0.33? we can branch off from this branch then make the PR to be merged into this PR as it has already been reviewed?

@melekes
Copy link
Contributor Author

melekes commented Nov 14, 2019

Impossible to merge master (too many conflicts). Will have to redo every step.

@melekes melekes closed this Nov 14, 2019
@melekes melekes deleted the anton/3853-rpc-ids branch November 15, 2019 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

R:major PR contains breaking changes that have to wait till a major release is made to be merged T:breaking Type: Breaking Change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Responses to "subscribe" sent over WebSocket don't conform to RPC 2.0 specification

5 participants