rpc: reset id and version per batch element #36642

pull fametrano wants to merge 1 commits into bitcoin:master from fametrano:rpc-batch-reset-id changing 2 files +19 −0

fametrano commented at 6:49 AM on October 24, 2026: none

In a JSON-RPC batch, an element that is not an object gets an error reply with the id and version of the element before it.

ExecuteHTTPRPC uses one request object for the whole batch. parse() throws on a non-object before it resets id and m_json_version. For [{"jsonrpc":"2.0","method":"getblockcount","id":"X"}, 2] the reply has two objects with "id":"X", one with a result and one with an error. If the first element is a notification, the error is dropped. I reset both fields at the top of parse(), so the error is the one the first element of a batch already gets. The new case in interface_rpc.py fails on master and passes with this change.

This is one of several PRs from a large audit of Bitcoin Core that I did with the help of LLM tools. The audit produced its evidence all at once, which is why the PRs arrive together. I understand each change fully and will answer review questions myself.

rpc: reset id and version per batch element

In a JSON-RPC batch, an element that is not an object gets an error
reply with the id and version of the element before it. A client that
matches replies by id can take that error for the result of the
previous call. If the previous element was a 2.0 notification, the
error is dropped.

I reset both at the start of JSONRPCRequest::parse(). The functional
test covers the two cases.

0811092e11

DrahtBot added the label RPC/REST/ZMQ on Oct 24, 2026
DrahtBot commented at 6:50 AM on October 24, 2026: contributor


The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



External sites
- Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36642
- Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36642.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36642#author-ralph


Reviews

See the guideline and AI policy for information on the review process.

Type Reviewers

ACK AndreaDiazCorreia

Concept ACK pinheadmz

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.
AndreaDiazCorreia commented at 2:05 AM on October 26, 2026: none

ACK 0811092e117f08ac9ad0e608f796cd8ac014abd0

Reviewed and tested, looks good to me.

Small nit: the existing m_json_version reset before the jsonrpc check is now redundant and could be removed.

Type	Reviewers
ACK	AndreaDiazCorreia
Concept ACK	pinheadmz

in src/rpc/request.cpp:206 in 0811092e11

 199 | @@ -200,6 +200,11 @@ std::vector<UniValue> JSONRPCProcessBatchReply(const UniValue& in)
 200 |  
 201 |  void JSONRPCRequest::parse(const UniValue& valRequest)
 202 |  {
 203 | +    // Start from the defaults, so that an error reply to a request that is
 204 | +    // not an object does not carry the id or version of a previous request
 205 | +    id = UniValue::VNULL;
 206 | +    m_json_version = JSONRPCVersion::V1_LEGACY;

pinheadmz commented at 8:01 PM on October 26, 2026:

remove the copy of this statement on line 221?

in test/functional/interface_rpc.py:185 in 0811092e11

 180 | +        self.log.info("Testing that an invalid batch element does not reuse the id or version of the previous one...")
 181 | +        invalid_element = {"result": None, "error": {"code": RPC_INVALID_REQUEST, "message": "Invalid Request object"}, "id": None}
 182 | +
 183 | +        response, status = send_json_rpc(self.nodes[0], [{"jsonrpc": "2.0", "method": "getblockcount", "id": "X"}, 2])
 184 | +        assert_equal(status, 200)
 185 | +        assert_equal(response, [{"jsonrpc": "2.0", "result": 0, "id": "X"}, invalid_element])

pinheadmz commented at 8:03 PM on October 26, 2026:

this is a little confusing to read, here and below. what if you just assert the response to the valid request is correct and the second response exists, and doesn't have the same id?

pinheadmz commented at 8:05 PM on October 26, 2026: member

concept ACK

This is a reasonable follow up to #27101 and fixes something we missed from the jsonrpc 2.0 spec that could confuse consumers of the interface expecting unique IDs in batch responses.

Contributors

Labels

rpc: reset id and version per batch element #36642

External sites

Reviews