paritytech / jsonrpsee

Rust JSON-RPC library on top of async/await

jsonrpsee

JSON-RPC library designed for async/await in Rust.

Designed to be the successor to ParityTech's JSONRPC crate.

Features

• Client/server HTTP/HTTP2 support
• Client/server WebSocket support
• Client WASM support via web-sys
• Client transport abstraction to provide custom transports
• Middleware

Documentation

• API Documentation

Examples

• HTTP
• WebSocket
• WebSocket pubsub
• API generation with proc macro
• CORS server
• Core client
• HTTP proxy middleware
• jsonrpsee as service
• low level API
• Websocket served over dual-stack (v4/v6) sockets

See this directory for more examples

Roadmap

See our tracking milestone for the upcoming stable v1.0 release.

Users

If your project uses jsonrpsee we would like to know. Please open a pull request and add your project to the list below:

• parity bridges common
• remote externalities
• substrate
• substrate-api-client
• subwasm
• subway
• subxt
• Trin
• Uptest
• zkSync Era
• Forest

Benchmarks

Daily benchmarks for jsonrpsee can be found:

• Gitlab machine: https://paritytech.github.io/jsonrpsee/bench/dev2

jsonrpsee's Issues

[server]: `unsubscribe_call` doesn't close subscriptions as intended

When an unsubscription call is received by the Server then RawServerSubscriptionId::from_wire_message tries to parse it from hardcoded JsonValue::Null where the subscription ID should be parsed instead. Thus, RawServerSubscriptionId::from_wire_message always fails to parse the subscription ID

This causes dropping a registered subscription not work with one exception when the entire client is dropped then it works via SubscriptionsClosed

Properly implement and test server-side subscriptions

There are drafts everywhere, but it's not properly implemented.

Flood of error messages when connection closes

When the connection is closed (because e.g. the server shuts down), there is an unending flood of these messages:

ERROR jsonrpsee::client] Client Error: Inner(Ws(Closed))

It would be nice if this error was handled a bit more graciously.

Unused type parameters when there is no function with a return value

Version: 0.1.0 (from crates.io)

I encountered an issue while trying to make a very small API for a test:

jsonrpsee::rpc_api! {
	Registrar {
		fn register_para(foo: i32, bar: String);
	}
}

I did this and it was failing with:

error[E0282]: type annotations needed
   --> test/parachain/tests/integration_test.rs:154:3
    |
154 |         Registrar::register_para(&mut client, 100, "{\"scheduling\":\"Always\"}").await.unwrap()
    |         ^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for type parameter `R` declared on the enum `Registrar`

(with more logs you can see that the type parameter I is also unused)

I expanded the code and this is what I get:

enum Registrar<'a, R, I> {
    RegisterPara { foo: i32, bar: String },
}

I changed it to:

jsonrpsee::rpc_api! {
	Registrar {
		#[rpc(method = "tx.registrar.registerPara")]
		fn register_para(foo: i32, bar: String) -> String; // <---- return value here
	}
}

And now R and I are used:

enum Registrar<'a, R, I> {
    RegisterPara {
        respond: jsonrpsee::raw::server::TypedResponder<'a, R, I, String>,
        foo: i32,
        bar: String,
    },
}

Need to be able to group generated APIs together and answer requests

When generating multiple APIs, we need to be able to group them together in order to call next_request once.

Implement jsonrpsee-ws

Waiting for the soketto crate to be up-to-date with new futures.

[ws server]: closes connection when deserialization fails for a request

Remove unnecessary allocations from the crate

There are several locations where we for example pass values by String when a &str would be enough.

[examples] rename subscriptions to ws_subscriptions

Is it better to rename this file to ws_subscription? Though http1.1 don't suppport subscription.

Originally posted by @yjhmelody in #180 (comment)

Clarify the client error situation

What happens when an error happens on the client side?
Everything in Client and RawClient regarding the behaviour after errors should be properly documented.

Client subscription termination

Subscriptions in the shared client look like they never terminate:

https://github.com/paritytech/jsonrpsee/blob/master/src/client.rs#L239-L250

When the receiver yields None, (which I understand means the stream is exhausted) it returns futures::pending!().

Also when using while let status = subscription.next().await we get the warning irrefutable while-let pattern.

Practically we break out of the loop when we receive the result we want e.g. https://github.com/paritytech/substrate-subxt/pull/58/files#diff-8776af0b15949a59471d9d5910b92db7R271. But what if the stream is closed (for whatever reason), presumably it will just hang?

[ws server]: hardcodes number of concurrent tasks to 8

Found the problem https://github.com/paritytech/jsonrpsee/blob/v2/src/ws/transport.rs#L352, it essentially just allows 8 concurrent tasks to be handled per connection, and if the buffer gets full -> deadlock

Originally posted by @niklasad1 in #156 (comment)

[ws server]: subscription response doesn't work missing `await`

See https://github.com/paritytech/jsonrpsee/blob/master/src/server.rs#L309-#L314

Should be:

       self.to_back.send(FrontToBack::SendOutNotif {
            unique_id: self.unique_id,
            notification: value,
        }).await;

[ws server]: only supports text `WebSocket messages`

The WebSocket server only allows text messages currently which need to fixed here: https://github.com/paritytech/jsonrpsee/blob/master/src/transport/ws/server.rs#L335.

For example, the client and server in this library won't work currently because the client sends messages as binary

Issue with client blocking when results array > 32 items

I have an RPC API Defined, and I've noticed that a client can hit 100% CPU awaiting the result for show_routes_learned here.

After much testing by changing the amount of data that's being returned (by altering advertised routes from a BGP peer) I found the following:

• I can reliably re-pro the blocking client and pegged CPU with 33+ items (example payload).
• When I have 32 or fewer items, the client behaves fine (example payload)
• I've mixed and matched different advertised routes and the one thing that is consistent is when I hit 33 or more items, the client blocks on the show_routes_learned call above.
• I know it's the client library because I can get the results from the server from Postman for 33+ results just fine.
• This seems to have broken sometime in the last month or so

I know this seems like a strange issue, please let me know if there's any other info I can provide to help troubleshoot!

Allow the types in rpc_api! to be generic

Within Substrate, for example, we want to be able to define things like:

rpc_api! {
    Interface<Block> { fn get_block() -> Block }
}

WASM friendly dependencies

Not only to make maintenance easier but also to potentially enable WASM compilation what about using higher level HTTP and WebSocket abstractions like surf(I guess better for async-std environments?) or reqwest and for WS perhaps something like ws_stream_wasm at least for the client stuff?

Server ignores subscription parameters

This is a big "oops" moment. Being able to pass parameters when subscribing is a pretty important aspect but that I completely forgot about.

At the moment the API of Server only exposes RegisteredSubscription::send in order to send a notification to all the clients that have subscribed, while in the clients can subscribe and unsubscribe without any consideration for the parameters that they passed.

from_value().request_by_id().await() hangs forever

I have the following very simple program:

jsonrpsee::rpc_api! {
    Filecoin {
        #[rpc(method = "Filecoin.ChainHead")]
        fn chain_head() -> String;
    }
}

fn main() {
    let result : String = async_std::task::block_on(async move {
        let transport =
            jsonrpsee::transport::http::HttpTransportClient::new("http://lotus1:1234/rpc/v0");
        let mut raw_client = jsonrpsee::raw::RawClient::new(transport);
        let request_id = raw_client.start_request("Filecoin.ChainHead", 
            jsonrpsee::common::Params::None).await.unwrap();
        println!("request_id={:?}",request_id);
        let ret = jsonrpsee::common::from_value(
            raw_client.request_by_id(request_id).unwrap().await.unwrap()
        )
        .unwrap();
        println!("This line is never reached.");
        return ret;
    });
    println!("result = {:?}", result);  // also never reached
}

When I run it, it hangs forever at request_by_id(request_id).unwrap().await():

$ ./target/debug/indexer
request_id=RawClientRequestId(0)

Using tcpdump on the server, I can see that jsonrpsee is sending a correct query:

	0x0030:            504f 5354 202f 7270 632f 7630      POST./rpc/v0
	0x0040:  2048 5454 502f 312e 310d 0a63 6f6e 7465  .HTTP/1.1..conte
	0x0050:  6e74 2d74 7970 653a 2061 7070 6c69 6361  nt-type:.applica
	0x0060:  7469 6f6e 2f6a 736f 6e0d 0a68 6f73 743a  tion/json..host:
	0x0070:  206c 6f74 7573 313a 3132 3334 0d0a 636f  .lotus1:1234..co
	0x0080:  6e74 656e 742d 6c65 6e67 7468 3a20 3638  ntent-length:.68
	0x0090:  0d0a 0d0a 7b22 6a73 6f6e 7270 6322 3a22  ....{"jsonrpc":"
	0x00a0:  322e 3022 2c22 6d65 7468 6f64 223a 2246  2.0","method":"F
	0x00b0:  696c 6563 6f69 6e2e 4368 6169 6e48 6561  ilecoin.ChainHea
	0x00c0:  6422 2c22 7061 7261 6d73 223a 6e75 6c6c  d","params":null
	0x00d0:  2c22 6964 223a 307d                      ,"id":0}

And the server is sending the correct response (same result it sends to curl):

                           4854 5450 2f31 2e31 2032 3030      HTTP/1.1.200
	0x0040:  204f 4b0d 0a44 6174 653a 2053 6174 2c20  .OK..Date:.Sat,.
	0x0050:  3131 204a 756c 2032 3032 3020 3034 3a35  11.Jul.2020.04:5
	0x0060:  343a 3039 2047 4d54 0d0a 436f 6e74 656e  4:09.GMT..Conten
	0x0070:  742d 5479 7065 3a20 7465 7874 2f70 6c61  t-Type:.text/pla
	0x0080:  696e 3b20 6368 6172 7365 743d 7574 662d  in;.charset=utf-
	0x0090:  380d 0a54 7261 6e73 6665 722d 456e 636f  8..Transfer-Enco
	0x00a0:  6469 6e67 3a20 6368 756e 6b65 640d 0a0d  ding:.chunked...
	0x00b0:  0a65 6264 0d0a 7b22 6a73 6f6e 7270 6322  .ebd..{"jsonrpc"
	0x00c0:  3a22 322e 3022 2c22 7265 7375 6c74 223a  :"2.0","result":
	0x00d0:  7b22 4369 6473 223a 5b7b 222f 223a 2262  {"Cids":[{"/":"b
	0x00e0:  6166 7932 627a 6163 6562 7733 6f37 6364  afy2bzacebw3o7cd
	0x00f0:  3772 6373 6e66 6d6b 746e 6c76 6d6d 7468  7rcsnfmktnlvmmth
	[...deleted...]
	0x03c0:  6b37 5647 2b62 6b65 4d52 5847 6471 354c  k7VG+bkeMRXGdq5L
	0x03d0:  5472 4f36 5559 5369 4c32 7465 5237 5845  TrO6UYSiL2teR7XE
	0x03e0:  3156 4943 6546 7a39 5732 6e56 3745 632b  1VICeFz9W2nV7Ec+
	0x03f0:  5668 3739 227d 2c22 466f 726b 5369 676e  Vh79"},"ForkSign
	0x0400:  616c 696e 6722 3a30 7d5d 2c22 4865 6967  aling":0}],"Heig
	0x0410:  6874 223a 3736 3733 377d 2c22 6964 223a  ht":76737},"id":
	0x0420:  307d                                     0}

I can't figure out why it's hanging. (The examples/polkadot.rs and examples/http.rs both work for me.)

Option for rpc_api macro to build client functions with positional params

Some RPC servers (like the old Parity JSONRPC one) do not accept requests with params provided by name (ie. as a JSON object). It would be nice to be able to build a compatible client using rpc_api. Currently, if an RPC method takes parameters, rpc_api will build a calling function that passes arguments by name, not by position.

Perhaps the RPC API struct (defined with the macro) should be instantiable with an options argument including disable_params_by_name: bool. Or an new "rpc(disable_params_by_name)" macro attribute, but that seems bad because it's part of the server implementation, not really part of the RPC API itself.

Defining a notification first fails to compile

I defined a notification method first inside of the rpc_api macro. This does result in a compilation error. Below the code snippet to reproduce:

jsonrpsee::rpc_api! {
    Logging {
        fn info(msg: String);
    }
}

fn main() {
    env_logger::try_init().ok();
    // Spawning a server in a background task.
    async_std::task::spawn(async move {
        let listen_addr = "127.0.0.1:8000".parse().unwrap();
        let mut server1 = jsonrpsee::http_raw_server(&listen_addr).await.unwrap();

        while let Ok(request) = Logging::next_request(&mut server1).await {
            match request {
                Logging::Info{ msg } => {
                    println!("{}", msg);
                }
            }
        }
    });

    // Client demo.
    let mut client = jsonrpsee::http_raw_client("http://127.0.0.1:8000");
    let v = async_std::task::block_on(async {
        Logging::info(&mut client, "some random message")
            .await
            .unwrap();
    });
    println!("{:?}", v);
}

Compiler error:

error[E0282]: type annotations needed
  --> src/lib.rs:30:29
   |
30 |     while let Ok(request) = Logging::next_request(&mut server).await {
   |                             ^^^^^^^^^^^^^^^^^^^^^ cannot infer type for `R`

error[E0282]: type annotations needed
  --> src/lib.rs:10:5
   |
10 | /     Logging {
11 | |         // fn enable(value: bool) -> bool;
12 | |
13 | |         fn info(msg: String);
   | |_______________^ cannot infer type for `R`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0282`.
error: could not compile `embedded-server`.

To learn more, run the command again with --verbose.

Adding a request above the notification makes the program compile (as seen in the http example).

Deadlock when request is issued when some subscription is active

Steps to repeat:

1. open a connection to the ws-server (e.g. substrate node);
2. subscribe to some notifications stream (e.g. to justifications using grandpa_justifications);
3. wait enough time for 5 notifications to be sent by the server (e.g. 20 blocks). DO NOT read any notifications from jsonrpsee::Subscription;
4. make request to the server (e.g. chain_getHeader) using the same client => deadlock.

The reason is that notifications channel is created with buffer size = 4. When we're trying to send 5th notification using blocking SinkExt::send().await here, the background thread will stop processing FrontToBack requests. So if we have single-threaded client, it'll block here, waiting for background thread to issue request and read response. At the same time, background thread is waiting for us to read pending notifications from the channel.

Update to futures 0.3

Blocked on hyperium/hyper#2007 and on soketto updating.

Panic when dropping a Client

In my project, I create a jsonrpc connection, get a subscription to some topic and occasionally drop the client and subscription. This usually results in a panic:

  0: std::sys_common::at_exit_imp::push
   1: core::fmt::ArgumentV1::show_usize
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
   6: std::panicking::try::do_call
   7: std::panicking::begin_panic
   8: std::panicking::begin_panic
   9: core::result::Result<T,E>::unwrap
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/result.rs:956
  10: jsonrpsee::client::background_task::{{closure}}
             at /Users/pepyakin/.cargo/git/checkouts/jsonrpsee-5ae67701a3cedc92/0e2b03f/src/client.rs:344
  11: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/future.rs:43
  12: std::future::poll_with_tls_context
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/future.rs:99
  13: jsonrpsee::client::Client::new::{{closure}}
             at /Users/pepyakin/.cargo/git/checkouts/jsonrpsee-5ae67701a3cedc92/0e2b03f/src/client.rs:128
  14: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/future.rs:43
  15: std::future::poll_with_tls_context
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/future.rs:99
  16: async_std::task::builder::Builder::spawn::{{closure}}
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/task/builder.rs:64
  17: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/future.rs:43
  18: async_task::raw::RawTask<F,R,S,T>::run
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-task-1.3.0/src/raw.rs:505
  19: async_task::task::Task<T>::run
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-task-1.3.0/src/task.rs:239
  20: async_std::task::builder::Runnable::run::{{closure}}::{{closure}}
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/task/builder.rs:81
  21: async_std::utils::abort_on_panic
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/utils.rs:16
  22: async_std::task::builder::Runnable::run::{{closure}}
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/task/builder.rs:81
  23: async_std::task::task::Task::set_current::{{closure}}
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/task/task.rs:129
  24: std::thread::local::LocalKey<T>::try_with
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/thread/local.rs:262
  25: std::thread::local::LocalKey<T>::with
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/thread/local.rs:239
  26: async_std::task::task::Task::set_current
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/task/task.rs:124
  27: async_std::task::builder::Runnable::run
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/task/builder.rs:81
  28: async_std::task::executor::pool::main_loop
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/task/executor/pool.rs:114
  29: core::ops::function::FnOnce::call_once
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/ops/function.rs:232
  30: async_std::utils::abort_on_panic
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/utils.rs:16
  31: async_std::task::executor::pool::POOL::{{closure}}::{{closure}}
             at /Users/pepyakin/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.4.0/src/task/executor/pool.rs:46

jsonrpsee API proc macros `unsupported`

Currently the jsonrpsee API proc macros are unsupported and that needs to be fixed.

It may be a bit difficult without any proper abstraction as a core-client and core-server.

Bad behavior when decoding server response fails

When decoding the server response fails due to the server response missing required fields, jsonrpsee seems to behave weirdly. Typically, it will hang for an indeterminate amount of time.

[ws transport]: soketto occasionally returns `UnexpectedOpCode(Continue)` when reading empty WebSocket message

I have noticed a difference between soketto v0.3 and soketto v0.4 where it sometimes reads an empty WebSocket message and returns UnexpectedOpCode(Continue).

For the client it doesn't make much difference than just that ERROR jsonrpsee::client::ws::client] Client Error: Inner(Ws(UnexpectedOpCode(Continue))) would be logged, still quite annoying.

For the server, it's critical because it would terminate the connection but I haven't seen it yet at least.... it might just soketto::Client related but receive_data and send_data seems to have the same implemetation.

Note: I tried to downgrade soketto v0.3.2 but it didn't manage to get the ws client/server to work.

Implement jsonrpsee-ipc

While the async-std crate provides Unix domain sockets, there's no new-futures equivalent of Windows named pipes.

Clean up the core/common directory

While all the structs are necessary and correctly designed, lots of methods are unused or are lacking. The general API could be improved.

Implement proper access control in jsonrpsee-http

Apply rustfmt on the codebase

• Apply rustfmt everywhere. I'll wait for #31 to be merged in order to not create unnecessary conflicts.
• Add a check in the CI.

#[rpc(method = "foo")] generates wrong method name

It calls the method \"foo\" instead of foo.

[CI]: benchmark github action doesn't work

https://github.com/paritytech/jsonrpsee/actions/runs/494859119

Fix crates.io crate version

Now, the crates.io version of this crate is 0.1.0, but version 1.0.0 specified in Cargo.toml. I think, crates.io version should be specified as 1.0.0

Add a local client/server for testing

Add an implementation of RawClient and an implementation of RawServer that wrap around channels, for local testing.

Question about plans for rpc_api macro workflow

Hi all, it looks like the current usage of the rpc_api!{} macro has some examples in the documentation. Unfortunately, when I try to modify these examples to take more of a task-based handling approach for requests, it appears that the presence of lifetimes in the data structures such as TypedResponder causes some problems. Because RawServer's &mut self reference in next_event must live for as long as the returned RawServerEvent, this causes problems when you try to send a RawServerEvent or similarly lifetime-oriented data structure to another thread to be processed. This causes the &mut self reference to require a lifetime of 'static. Do you have suggestions for working around this? Will this be changed in the 0.2.0 release?

HTTP background thread consumes 100% CPU

The reason is that FuturesUnordered::poll_next() always returns Poll::Ready(None) if it is empty (at the start), or when all its futures have completed. So we instantly wake up here and proceed to the next iteration.

Bonus issue: it seems that completed futures are never removed from pending_requests.

Properly implement and test client-side subscriptions

The rpc_api! macro should provide a way to start a subscription and listen to events returned by the server.

Nothing has been started here, at all.

Make library compile for wasm32-wasi

It would be great to be able to build a JSON-RPC 2.0 server that targets wasm32-wasi. The use case I'd like to support is the same as https://github.com/paritytech/jsonrpc/tree/master/stdio where the transport is stdio.

Today, if you try to cargo build --target=wasm32-wasi this project, socket2 fails to build. It would be nice to make that an optional dependency that is not included when a wasm32-wasi target.

I first looked at https://paritytech.github.io/jsonrpc/jsonrpc_core/index.html, but it is still using futures 0.1. paritytech/jsonrpc#485 mentioned having a look at this project instead. It would be nice if the transport agnostic "core" was still possible.

It is okay if this feature does not match this project's roadmap. I'm just trying to find out what can be reused and where collaborations can be made. Due to chemotherapy, my personal time investment may be low over the next three months. I'm hoping I can spark some ideas for others.

[ws client]: ChannelClosed message should embed `request_id`

When a subscription is closed, all the subscriptions are iterated over and returns once a closed subscription is found, which is inefficient and could close the wrong subscription if "several are closed at the same time", see https://github.com/paritytech/jsonrpsee/blob/v2/src/client/ws/client.rs#L303-#L309

Thus, it would be better to just have ChannelClosed(RequestId) than it could be performed in constant time and is correct.

[ws server]: should reply `parse_error` when deserialization fails

The server should reply with -32700 Parse error when the deserialization fails, see https://github.com/paritytech/jsonrpsee/blob/master/src/transport/ws/server.rs#L339-#L342

[websocket client]: Non-deterministic connection dropping

While using the websocket client against a substrate node it non-deterministically drops the connection. As far as I can see there is no per-request timeout so this can indefinitely hang. I wish I had a better reproduction for this issue, but every time we add trace logs the bug no longer occurs. I'll dump whatever information I can into this ticket.

Q: meaning of `self.responses.next()` returning `None`?

When making a rpc call with client.request("<rpc method name>", params).await I'm seeing several errors like this:

[2020-07-01T15:03:49Z ERROR jsonrpsee::transport::http::client] JSONRPC http client background thread has shut down
[2020-07-01T15:03:49Z ERROR jsonrpsee::client] Client Error: Inner(Http(Custom { kind: Other, error: "background thread is down" }))
[2020-07-01T15:03:49Z ERROR jsonrpsee::transport::http::client] JSONRPC http client background thread has shut down
[2020-07-01T15:03:49Z ERROR jsonrpsee::client] Client Error: Inner(Http(Custom { kind: Other, error: "background thread is down" }))
[2020-07-01T15:03:49Z ERROR jsonrpsee::transport::http::client] JSONRPC http client background thread has shut down
[2020-07-01T15:03:49Z ERROR jsonrpsee::client] Client Error: Inner(Http(Custom { kind: Other, error: "background thread is down" }))

The error comes from here, where self.responses.next() is returning a None and we end up in the error case; the RawClientEvent received from the server (here) looks like this: Response { request_id: RawClientRequestId(0), result: Ok(Null) }.
When I log at trace level I (unsurprisingly?) see several calls to next_responses() being performed until the request receives a response. The RPC call is performed correctly so the errors seem spurious. Running my code in release mode makes the problem go away (no errors printed); adding a pause of 1ms after the call to client.request() also "fixes" it.

I am uncertain of what the meaning of a None is but I imagine it simply means that there is no response to read, which is not an error?

Here's the code I run:

async fn insert_signing_key(url: &str) -> Result<(), Box<dyn std::error::Error>> {
    let client = jsonrpsee::http_client(url);
    let params = Params::Array(vec![to_value("sgx!")?, to_value("//Alice")?, to_value("0x123")?]);
    client.request("author_insertKey", params).await.map_err(Into::into)
}

I guess I have several questions:

1. is this a bug in jsonrpsee or is the problem rather on the server (a substrate node).
2. I am not sure if the json Null values are actually part of the server payload or some default value that jsonrpsee makes up on the fly.
3. I am not sure if next_responses() is correct in assuming None is an error, but if it's wrong, what should it do? Returning an Ok with an empty body doesn't seem right either.

[raw server]: debug implementation for Params::Array is missing

Debug implementation for Params::Array is missing, see https://github.com/paritytech/jsonrpsee/blob/master/src/raw/server/params.rs#L89

Lot of warnings from within the macro

I'm getting a lot of warnings during the compilation:

   |
   = note: `#[warn(unused_variables)]` on by default

warning: unused variable: `method`
  --> test/parachain/tests/integration_test.rs:50:2
   |
50 |     Chain {
   |     ^^^^^ help: consider prefixing with an underscore: `_method`

warning: unused variable: `request`
  --> test/parachain/tests/integration_test.rs:52:3
   |
52 |         fn current_block_hash() -> PHash;
   |         ^^ help: consider prefixing with an underscore: `_request`

warning: unused variable: `method`
  --> test/parachain/tests/integration_test.rs:61:2
   |
61 |     State {
   |     ^^^^^ help: consider prefixing with an underscore: `_method`

warning: unused variable: `request`
  --> test/parachain/tests/integration_test.rs:63:3
   |
63 |         fn runtime_version() -> RuntimeVersion;
   |         ^^ help: consider prefixing with an underscore: `_request`

warning: variant is never constructed: `SubmitExtrinsic`
  --> test/parachain/tests/integration_test.rs:47:6
   |
47 |         fn submit_extrinsic(extrinsic: String) -> PHash;
   |            ^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

warning: method is never used: `next_request`
  --> test/parachain/tests/integration_test.rs:45:2
   |
45 |     Author {
   |     ^^^^^^

warning: variant is never constructed: `CurrentBlockHash`
  --> test/parachain/tests/integration_test.rs:52:6
   |
52 |         fn current_block_hash() -> PHash;
   |            ^^^^^^^^^^^^^^^^^^

warning: variant is never constructed: `Header`
  --> test/parachain/tests/integration_test.rs:55:6
   |
55 |         fn header(hash: PHash) -> Option<Header>;
   |            ^^^^^^

warning: variant is never constructed: `BlockHash`
  --> test/parachain/tests/integration_test.rs:58:6
   |
58 |         fn block_hash(hash: Option<u64>) -> Option<PHash>;
   |            ^^^^^^^^^^

warning: method is never used: `next_request`
  --> test/parachain/tests/integration_test.rs:50:2
   |
50 |     Chain {
   |     ^^^^^

warning: method is never used: `current_block_hash`
  --> test/parachain/tests/integration_test.rs:52:3
   |
52 |         fn current_block_hash() -> PHash;
   |         ^^

warning: variant is never constructed: `RuntimeVersion`
  --> test/parachain/tests/integration_test.rs:63:6
   |
63 |         fn runtime_version() -> RuntimeVersion;
   |            ^^^^^^^^^^^^^^^

warning: method is never used: `next_request`
  --> test/parachain/tests/integration_test.rs:61:2
   |
61 |     State {
   |     ^^^^^

The code is located there.

It is strange because everything is used. But I only use it as client, not as server, maybe that is why I get so many warnings.

Renaming Function Parameters for Client API

I am trying to create a client that interacts with a server, however I am running into a small issue when attempting to send a request. Specifically, the params are not being serialized the correct way.

Currently a valid serialization of the params would look like this :
"params" : [{"/":"bafy2bzacea3wsdh6y3a36tb3skempjoxqpuyompjbmfeyf34fi3uy6uue42v4"}]

However the request that is being sent has a params field that looks like this :
"params":{"params":"bafy2bzacecujyfvb74s7xxnlajidxpgcpk6abyatk62dlhgq6gcob3iixhgom"}

Currently my client API is defined as :

I understand that the reason the request is incorrect is because it is using "params" instead of "/". However I am not sure how to fix the issue. Is there a way to rename the method parameter so when it is serialized, it uses "/" instead of "params" or is there a much more simple solution?

Support no_std

Blocked by serde-rs/json#362

Batch Requests

I'm wondering about the plans to implement batch requests for the client. I saw a 'Batch' variant in the request enum, however, it seems like that's not being used in RawClient or the FrontToBack/request method in client.rs is for singular requests. This is my first look at the code, but would it be correct to just add a batch_request method to add that logic/modify the enum variants and allow front-end batch-requests?

Add a SharedClient and SharedServer

After some discussion with @jimpo, let's make the API more convenient to use.

As a first step, let's add a SharedClient and a SharedServer. See the sketches below.
As a second step, let's rename things around: RawClient/RawServer should become ClientTransport/ServerTransport, Client/Server should become RawClient/RawServer, and SharedClient/SharedServer should become Client/Server.

Sketches for the new API layers:

impl SharedClient<...> {
    pub async fn request<Ret>(&self, method: ..., params: ...) -> Ret;
    pub async fn subscribe(&self, method: ..., params: ...) -> Subscription;
}

impl Subscription {
    pub async fn next(&mut self) -> ...;
}

impl Drop for Subscription {
    ...  // unsubscribes
}

impl SharedServer<...> {
    /// Registers a request that the server must handle. Returns an error if already registered.
    pub fn register_request<Params, Ret>(&self, method: ...) -> RequestHandler<Params, Ret>;
    pub fn register_subscription<Notif>(&self, subscribe_method: ..., unsubscribe_method: ...) -> Subscription<Notif>;
}

impl<Params, Ret> RequestHandler<Params, Ret> {
    /// User must call this repeatedly and answer the requests.
    pub async fn next(&mut self) -> ...;
}

impl<Notif> Subscription<Notif> {
    pub async fn send_all(&self, to_send: Notif) { ... }
}

[websocket example]: TLS doesn't work

Running `target/debug/examples/ws`
[2020-12-15T11:57:58Z TRACE jsonrpsee::ws::server] [frontend]: register_method=say_hello
[2020-12-15T11:57:58Z TRACE jsonrpsee::ws::server] [backend]: register_method: "say_hello"
[2020-12-15T11:57:58Z TRACE jsonrpsee::ws::transport] 1: new connection
Error: TransportError(Connect(Io(Custom { kind: UnexpectedEof, error: "tls handshake eof" })))