Add a dev notes document describing the new wallet RPC blocking
This commit is contained in:
parent
3ea8b75281
commit
c4784b5065
1 changed files with 13 additions and 0 deletions
|
@ -644,3 +644,16 @@ A few guidelines for introducing and reviewing new RPC interfaces:
|
||||||
|
|
||||||
- *Rationale*: If a RPC response is not a JSON object then it is harder to avoid API breakage if
|
- *Rationale*: If a RPC response is not a JSON object then it is harder to avoid API breakage if
|
||||||
new data in the response is needed.
|
new data in the response is needed.
|
||||||
|
|
||||||
|
- Wallet RPCs call BlockUntilSyncedToCurrentChain to maintain consistency with
|
||||||
|
`getblockchaininfo`'s state immediately prior to the call's execution. Wallet
|
||||||
|
RPCs whose behavior does *not* depend on the current chainstate may omit this
|
||||||
|
call.
|
||||||
|
|
||||||
|
- *Rationale*: In previous versions of Bitcoin Core, the wallet was always
|
||||||
|
in-sync with the chainstate (by virtue of them all being updated in the
|
||||||
|
same cs_main lock). In order to maintain the behavior that wallet RPCs
|
||||||
|
return results as of at least the highest best-known block an RPC
|
||||||
|
client may be aware of prior to entering a wallet RPC call, we must block
|
||||||
|
until the wallet is caught up to the chainstate as of the RPC call's entry.
|
||||||
|
This also makes the API much easier for RPC clients to reason about.
|
||||||
|
|
Loading…
Reference in a new issue