Skip to content

WIP: Create an async corepc-client (adding async support to jsonrpc)#505

Draft
jamillambert wants to merge 7 commits intorust-bitcoin:masterfrom
jamillambert:0212-WIP-client-async
Draft

WIP: Create an async corepc-client (adding async support to jsonrpc)#505
jamillambert wants to merge 7 commits intorust-bitcoin:masterfrom
jamillambert:0212-WIP-client-async

Conversation

@jamillambert
Copy link
Collaborator

@jamillambert jamillambert commented Feb 12, 2026

Not a merge candidate. Proof of concept only.

This is PR option 1 of 2, both add an async corepc-client but in a slightly different ways. This version adds async support to jsonrpc, the other adds the required part of jsonrpc into corepc-client (#506).

The patches are structured to make it easier to see what was changed from sync to async. First the sync version is copied and renamed, then in a separate patch it is changed to async.

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. These can be
added back later once the async version is working.
In preparation for adding bitreq_http_async feature to jsonrpc move
the sync version to the client-sync feature so it is not always on
with jsonrpc.
Create a new folder for the upcoming async client and copy in the
existing client_sync code.

Code copy only to make the next patch easier to review.
Edit the copy of the sync client created in the previous commit to be
async. Update the readme and cargo.toml files.

Add only small set of RPCs.
@jamillambert jamillambert changed the title WIP: Create an async corepc-client by adding async support to jsonrpc WIP: Create an async corepc-client (adding async support to jsonrpc) Feb 12, 2026
Add some vibe coded tests for the async client to check that everything
is functional. Tests are for development purposes only to catch simple
errors like feature gates etc. and have not been reviewed.
/// Creates a new client with the given transport.
pub fn with_transport<T: Transport>(transport: T) -> Client {
Client { transport: Box::new(transport), nonce: atomic::AtomicUsize::new(1) }
pub fn with_transport<T: AsyncTransport>(transport: T) -> AsyncClient {
Copy link
Member

Choose a reason for hiding this comment

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

My suggestion would be to not rename these types. That way the diff is smaller. I'd rename client.rs to client_sync.rs. You'll need to remove the public re-exports from lib.rs and that maybe fix up some paths to always use client_sync:: or client_async:: as appropriate.

# A transport that uses `bitreq` as the async HTTP client.
bitreq_http_async = [ "base64", "bitreq", "bitreq/async" ]
# An async JSON-RPC client implementation.
client_async = []
Copy link
Member

Choose a reason for hiding this comment

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

Maybe this feature should enable bitreq_http_async?

@@ -22,6 +22,10 @@ default = [ "simple_http", "simple_tcp" ]
simple_http = [ "base64" ]
# A transport that uses `bitreq` as the HTTP client.
bitreq_http = [ "base64", "bitreq" ]
Copy link
Member

Choose a reason for hiding this comment

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

Maybe this should be re-name to bitreq_http_sync?

@tcharding
Copy link
Member

@apoelstra whats your take man? Would you be willing to have jsonrpc take changes to be able to use bitreq in an async manner? It obviously smashes the dep tree if --all-features are used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants