The new getblockfrompeer RPC lacks test coverage for invalid arguments, and its error messages are not harmonized with the existing RPCs.
Fix all issues.
The new getblockfrompeer RPC lacks test coverage for invalid arguments, and its error messages are not harmonized with the existing RPCs.
Fix all issues.
Closes #24943.
Pretty sure the changes here have nothing to do with the issue. The issue report is about bitcoin-cli. Here, you are modifying the server code.
438@@ -439,6 +439,11 @@ static RPCHelpMan getblockfrompeer()
439 },
440 [&](const RPCHelpMan& self, const JSONRPCRequest& request) -> UniValue
441 {
442+ RPCTypeCheck(request.params, {
443+ UniValue::VSTR, // blockhash
444+ UniValue::VNUM, // peer_id
445+ }, true);
get_int64
should already throw, so maybe the error string of get_int64
can be adjusted instead? Otherwise, I’d suggest to do this in RPCHelpMan
somehow automatically instead of forcing reviewers and devs to do it manually.
It throws with the internal-style error seen in the previously referenced issue, but we do the same standard type check and user-friendly error message in many RPCs:
scantxoutset sendrawtransaction testmempoolaccept estimatesmartfee estimaterawfee getdescriptorinfo deriveaddresses setmocktime mockscheduler addconnection createrawtransaction decodescript signrawtransactionwithkey decodepsbt combinepsbt finalizepsbt createpsbt converttopsbt utxoupdatepsbt joinpsbts analyzepsbt upgradewallet importmulti importdescriptors lockunspent getunconfirmedbalance walletcreatefundedpsbt walletprocesspsbt send fundrawtransaction bumpfee psbtbumpfee
…and the new sendall RPC.
So it seems correct to do it here as well (and the change is trivial to review). If you disagree, can you clarify further? Alternatively, could just drop the second commit and add test coverage only.
gettxout
is a “real” RPC and isn’t checked either, so I don’t see why this one should be checked for “harmony” as well.
Recall that this is a test-only RPC, so any effort spent on it won’t be visible by users.
JSON value is not X
message be changed to the Expected type X, got Y
messages in many of our RPCs, but the former are in the external UniValue library. I’m not yet clear how your suggestion ties in with that, but can drop the second commit here (I still think it’s an improvement ATM though).
nit: This RPC does not accept null params.
0 RPCTypeCheck(request.params, {
1 UniValue::VSTR, // blockhash
2 UniValue::VNUM, // peer_id
3 });
edited comment (https://github.com/bitcoin/bitcoin/pull/24944#issuecomment-1167214427) due to a bug or feature (?) in github-merge.py:
0Merge message contains an @!
1---------------------------------------------------------------------------
2Merge bitcoin/bitcoin#24944: rpc: add getblockfrompeer RPCTypeCheck and invalid input test coverage
3
42ef5294a5bb68ceb3797d2638567a172cc21699f rpc: add RPCTypeCheck for getblockfrompeer inputs (Jon Atack)
5734b9669ff7b2f5e2820993443a6f868f6b0b20a test: add getblockfrompeer coverage of invalid inputs (Jon Atack)
6
7Pull request description:
8
9 The new getblockfrompeer RPC lacks test coverage for invalid arguments, and its error messages are not harmonized with the existing RPCs.
10
11 Fix all issues.
12
13
14ACKs for top commit:
15 jonatack:
16 Thanks [@luke-jr](/bitcoin-bitcoin/contributor/luke-jr/) and [@w0xlt](/bitcoin-bitcoin/contributor/w0xlt/) for the ACKs, updated per `git diff a926025 2ef5294` to take [@w0xlt](/bitcoin-bitcoin/contributor/w0xlt/)'s suggestion.
17 brunoerg:
18 ACK 2ef5294a5bb68ceb3797d2638567a172cc21699f
RPCTypeCheck
to be run internally and consistently on all methods, not intermittently on only those that it was added to. See also #24944 (review)