jsonrpc: Add async support by jamillambert · Pull Request #558 · rust-bitcoin/corepc

jamillambert · 2026-04-17T14:40:34Z

Pulled out of #505 and polished.

The aim is to add async support without breaking existing sync downstream. This includes keeping the reexports of the current sync Client at the crate root.

Code copy only to make it easier in the next patch to see what the changes are for async.

Remove code related to fuzzing from the new async files. Fuzzing of the async client can be added back later if needed.

In preparation for adding another async client change the Debug impl to refer to the local sync Client so that there is no conflict when adding the second async Client struct.

satsfy

tACK 5906ce1 - Ran some async tests locally with the new client.

satsfy · 2026-04-17T16:14:42Z

+
+impl BitreqHttpTransport {
+    /// Constructs a new [`BitreqHttpTransport`] with default parameters.
+    pub fn new() -> Self { BitreqHttpTransport::default() }


Just a comment. Should we consider some validation here? So that the user cannot shoot themselves on the foot like:

use jsonrpc::bitreq_http_async::Builder; Builder::new().url("not_a_url").is_ok();

I suppose a validation could happen at new or at fn build(self). No change required, because sync client also does it too. But it's a thought for production.

Raise an issue man, your thoughts are valuable and will be lost if left here!

Worth raising an issue. But not_a_url is a valid URL. I'm not sure what validation would be reasonable.

Thanks I'll put it on the production client's existing issue as an additional consideration.

@satsfy have you spent much time with async code?

@tcharding I don't have enough async experience for a decisive review.

tcharding

ACK 5906ce1 - but I know nothing about async code.

tcharding · 2026-04-18T02:52:40Z

Since we are going to cut a release that includes code I know nothing about (async) I'd love to see PRs up that test everything before we release. Would you consider doing:

A release tracking PR for jsonrpc (bumps version and updates local crates that depend on it).
Rebase the prod RPC client and use the branch/PR created above

Then with green CI on those two PRs we'd have confidence we got things right and we can go ahead and cut the releases.

And if someone with async experience has ten minutes to cast an eye over 5906ce1 please that would be very much appreciated.

tcharding · 2026-04-18T02:53:15Z

@satsfy have you spent much time with async code?

apoelstra · 2026-04-18T13:47:31Z

I have a reasonable amount of experience with async. I'll take a look.

apoelstra · 2026-04-18T15:01:26Z

    pub fn builder() -> Builder { Builder::new() }

-    fn request<R>(&self, req: impl serde::Serialize) -> Result<R, Error>
+    /// Returns the timeout in whole seconds, rounding positive sub-second values up to one.


In 5906ce1:

This is fine, but shouldn't it be done in a separate commit and be done for the sync version too?

apoelstra · 2026-04-18T15:04:00Z

+        &'a self,
+        req: Request<'a>,
+    ) -> BoxFuture<'a, Result<Response, crate::Error>> {
+        Box::pin(async move { Ok(self.request(req).await?) })


In 5906ce1:

This mess can be replaced with Box::pin(self.request(req))

apoelstra · 2026-04-18T15:04:15Z

+        &'a self,
+        reqs: &'a [Request<'a>],
+    ) -> BoxFuture<'a, Result<Vec<Response>, crate::Error>> {
+        Box::pin(async move { Ok(self.request(reqs).await?) })


In 5906ce1:

...and this one with Box::pin(self.request(reqs))

apoelstra · 2026-04-18T15:08:54Z

-        fn send_request(&self, _: Request) -> Result<Response, Error> { Err(Error::NonceMismatch) }
-        fn send_batch(&self, _: &[Request]) -> Result<Vec<Response>, Error> { Ok(vec![]) }
+        fn send_request<'a>(&'a self, _: Request<'a>) -> BoxFuture<'a, Result<Response, Error>> {
+            Box::pin(async { Err(Error::NonceMismatch) })


In 5906ce1:

This is just a style thing but you can write Box::pin(futures::err(Error::NonceMismatch)) here. It might even compile faster or more efficiently.

apoelstra · 2026-04-18T15:09:14Z

+            &'a self,
+            _: &'a [Request<'a>],
+        ) -> BoxFuture<'a, Result<Vec<Response>, Error>> {
+            Box::pin(async { Ok(vec![]) })


In 5906ce1:

Similarly, futures::ok(vec![])

apoelstra · 2026-04-18T15:11:32Z

-    pub fn send_request(&self, request: Request) -> Result<Response, Error> {
-        self.transport.send_request(request)
+    pub async fn send_request(&self, request: Request<'_>) -> Result<Response, Error> {
+        self.transport.send_request(request).await


In 5906ce1:

It might not be worth the abstraction leak, but you can change this method to return a BoxFuture and then you don't need async or await (and the resulting code will be smaller and faster to compile since it saves you a dummy state machine).

jamillambert added 4 commits April 17, 2026 15:33

Copy jsonrpc client and bitreq_http for async.

f92e625

Code copy only to make it easier in the next patch to see what the changes are for async.

Remove fuzz related sections

9b7fabe

Remove code related to fuzzing from the new async files. Fuzzing of the async client can be added back later if needed.

Change Debug impl to local Client

261068a

In preparation for adding another async client change the Debug impl to refer to the local sync Client so that there is no conflict when adding the second async Client struct.

Add async support to jsonrpc

5906ce1

jamillambert requested a review from tcharding April 17, 2026 14:40

jamillambert requested a review from apoelstra as a code owner April 17, 2026 14:40

github-actions bot added the C-jsonrpc label Apr 17, 2026

satsfy approved these changes Apr 17, 2026

View reviewed changes

tcharding approved these changes Apr 18, 2026

View reviewed changes

apoelstra reviewed Apr 18, 2026

View reviewed changes

Conversation

jamillambert commented Apr 17, 2026

Uh oh!

satsfy left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

satsfy Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tcharding left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tcharding commented Apr 18, 2026

Uh oh!

tcharding commented Apr 18, 2026

Uh oh!

apoelstra commented Apr 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

satsfy left a comment •

edited

Loading

satsfy Apr 18, 2026 •

edited

Loading

tcharding left a comment •

edited

Loading