Add Chain interface#22
Draft
Sjors wants to merge 6 commits into
Draft
Conversation
Sjors
force-pushed
the
2026/04/chain-interface
branch
from
a804e4f to
62845e2
Compare
…livery Two new tests against the multiprocess regtest node: - chain_handle_notifications_delivers_mempool_added: registers a ChainNotifications::Server via handleNotifications, injects a self-transfer through bitcoin-cli on a blocking task, and waits for the corresponding transactionAddedToMempool callback. - chain_request_mempool_transactions_replays_current_mempool: seeds the mempool with a self-transfer, then calls requestMempoolTransactions and confirms the existing entry is replayed through the same notifications interface (no separate getrawmempool call needed). Together these cover the two paths electrs needs to drop its bitcoind JSON-RPC mempool plumbing on the IPC backend.
CI runs have shown several Chain notification tests hanging indefinitely when the underlying call gets stuck (e.g. a stale node, a server-side bug, or a missed wakeup). Without an explicit cap, the cargo test process keeps the runner busy until the job-level timeout fires and then prints "has been running for over 60 seconds" with no further diagnostics. Wrap the `with_init_client` body in a 30s `tokio::time::timeout` so a stuck test fails fast with a clear message identifying the budget. 30s is well above the happy-path runtime of every test in this file (none exceed a few seconds against a warm regtest node) and above the in-test timeouts (15s) used by the notification suite.
Two new integration tests covering the fee-related Chain methods electrs
needs to drop its `getnetworkinfo.relayfee` and `estimatesmartfee` JSON-RPC
calls on the IPC backend:
- chain_relay_min_fee_returns_default: confirms regtest returns the
DEFAULT_MIN_RELAY_TX_FEE (100 sat/kvB) value.
- chain_estimate_smart_fee_returns_decodable_blob: confirms the response
decodes as a CFeeRate even when the smart fee estimator has no data
(regtest case).
Also documents the on-the-wire layout of CFeeRate (FeeFrac { int64_t fee;
int32_t size; } -> 12 bytes LE) in a small helper, since CFeeRate is
serialized via Bitcoin Core SERIALIZE_METHODS rather than a Cap'n Proto
struct -- so the encoding is not visible from the .capnp schema alone.
Sjors
force-pushed
the
2026/04/chain-interface
branch
from
7eb1b72 to
db5fa57
Compare
Sjors
force-pushed
the
2026/04/chain-interface
branch
from
8fe6720 to
fca8cac
Compare
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.
Corresponds to bitcoin/bitcoin#29409
We still need to figure out which, if any, of these chain methods will be declared stable. And then if we want to limit bindings to the stable interface.
But for now, this can be used for testing.
TODO: expand test coverage