Client 20 06 26#643
Closed
satsfy wants to merge 21 commits into
Closed
Conversation
params.host is already a reference; taking another borrow trips clippy::needless_borrow once the async transport paths are exercised by the workspace lint job.
Add the OpenRPC JSON exports for Bitcoin Core v17 through v31, one per release, produced by a Core patch that adds a getopenrpcinfo RPC (see specs/README.md for the per-version branches). They are the source of truth the bindings generator consumes and make regeneration reproducible.
Add crate btc-codegen, a standalone tool that generates the Rust JSON-RPC
bindings for a Bitcoin Core version from its OpenRPC spec. It parses
the spec (src/spec.rs), lowers methods and schemas to typed Rust
(src/codegen.rs), and emits modules into the sibling crates. Tesponse
types and their strongly typed model conversions into types, and
the call surface (request structs plus async method wrappers) into client.
Identifier splitting is driven by a word list with a greedy longest match
scan and various boundary rules (src/names.rs).
Generated files are committed in the consumers and regenerated
by maintainers via the root justfile recipe `just codegen {version}` (where
version can be 30, 29... or 'all') and cleaned up with `just codegen clean`.
Add a production-oriented async JSON-RPC client behind the client-async feature. The runtime core is small: a Builder validating URL, auth (user/pass or Core cookie file, resolved once at build time) and timeout; a Client that is cheap to clone and exposes call_raw as the escape hatch for any method; and a structured error model that preserves Core RPC codes, classifies retryability, lifts HTTP 401/403 to an Auth error and Core -32601 to a VersionMismatch against the compiled version feature. The v30 method surface is generated by codegen from the OpenRPC spec: one wrapper per RPC returning the generated response type from corepc-types, plus, for every RPC with optional positional arguments, a _with overload taking a *Options struct defined next to the methods (one Option<T> per optional argument; an unset field is sent as JSON null, which Core reads as use-the-default, or omitted from an options object). A hermetic stub-transport test suite pins the end-to-end shape: argument encoding including null padding for skipped positional arguments, object-mode option omission, error mapping and retryability classification. Lock files gain the tokio dev-dependency the tests use.
Add a sync-API client behind the blocking feature that exposes the same v30 method surface as the sync test client (same names, argument types and curated return types) but drives every call through the generated async client on a current-thread tokio runtime. Generated return types are bridged to the curated vtype types by a JSON round-trip, both being serde views of the same Core response, so the unchanged integration test suite exercises the async transport and the generated code end to end. RPC application errors keep their Core code and message through the sync JsonRpc error variant so error-code inspection behaves the same against either client, and the transport timeout matches the sync client 60 second budget the test suite is calibrated against. Methods without a generated async wrapper (the Generating, Hidden and Zmq help sections) fall back to the sync client macros over the same transport, which needs the client_sync error module to be public.
Add a client-async feature that backs node.client with the async client blocking facade instead of the sync client. Only meaningful with the 30_2 version feature (the async client targets v30); a cfg guard keeps --all-features resolving to the sync client, pinned by an inert type-check test that only compiles under that combination.
Add a test-async feature that swaps node.client to the async-backed blocking facade, so the existing tests exercise the async transport unchanged. Document how to run them in the README. tests/async.rs is a reference suite: each test pins one design decision of the async client (the facade as real transport, the generated-to-curated type bridge, into_model conversion, the name bridge for verbosity methods, per-level typed verbosity methods, the raw call escape hatch, and null-for-default optional arguments) with a live assertion against a real node, so the reference cannot silently rot.
The generator lives in its own Cargo workspace, so none of the root jobs built or tested it; add a job that tests, lints and format-checks it, mirroring the Verify job pattern for out-of-workspace crates. Add an integration job that runs the suite against the async client (v30, test-async feature) alongside the existing per-version sync jobs.
The repository README told production users to write their own client and the crate README said corepc-client is only a blocking client for integration testing; both predate the generated async client. Describe the two clients and their features, point at the codegen tool, and scope the do-not-use-in-production warning to the blocking test client.
…clean generated v31 facade; shared setup for the 3 get_address_info async MVPs
get_address_info via type-swap. Reuse the sync impl_client_v17__get_address_info macro unchanged; flip its return type to the GENERATED GetAddressInfo with a single use-shadow (call-site type resolution), and override vtype. Covers transport + generated into_model (layer 3). Smallest diff; no method body.
satsfy
requested review from
RCasatta,
TheBlueMatt,
jamillambert,
oleonardolima,
tcharding and
tnull
as code owners
Contributor
Author
|
Sorry targeted upstream accidentally. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.