Review report

WhitelistErrorBatch joins every distinct denied method name without bounding count or length, then copies the complete summary into each permitted, parseable, non-notification member's -39 error. For a user permitted to call getblockcount, one denied name of 1 MiB followed by 4096 legacy {"method":"getblockcount"} members requires about 4 GiB of message copies from roughly 1.1 MiB of input. Legacy members without IDs are not notifications. Serialization adds more storage, and neither the 32 MiB input limit nor send-buffer backpressure bounds this construction. Base returned an empty 403 at the first denial. Separately, the vector-based deduplication takes O(K²) comparisons for K distinct denied names, occupying one worker without a cancellation check. Users denied all methods through -rpcwhitelistdefault now reach that path too. These are source-derived costs, not measured peaks or durations; memory exhaustion may terminate the process or produce a recoverable allocation failure and HTTP 500, depending on the platform. Bound the collected name count and each name's length before building the summary, stop deduplicating once that budget is reached, and indicate truncation. This preserves whole-batch refusal and the per-member error codes. Add a regression test that combines a long denied name with many permitted members and checks bounded reply growth.

When the initial getnewaddress call succeeds, CommandLineRPC sends generatetoaddress through GenerateToAddressRequestHandler as JSON-RPC 2.0. The new HTTP 200 response containing -38 reaches ProcessReply, which reads only result and constructs a replacement reply with no error. The missing result becomes null, so the CLI prints an address with "blocks": null and exits 0 even though generation did not run. The handler omission predates this PR, but changing whitelist denials from empty HTTP 403 responses to JSON-RPC errors newly exposes it for these refusals. Return the original reply unchanged when its error is non-null, and add a whitelist test that permits getnewaddress, denies generatetoaddress, and checks the permission message and nonzero exit. No deployment with this exact whitelist split was identified, so production impact is unconfirmed.

When no string method in the batch is denied, the preflight now skips non-object members and passes them to the ordinary execution loop. That loop reuses jreq, while parse() rejects a non-object before resetting its ID or version. With getblockcount permitted, [{"jsonrpc":"2.0","method":"getblockcount","id":0},7] therefore produces both the success and invalid-request error with ID 0. Omitting the first member's ID instead makes the scalar inherit notification state, suppresses its error, and yields HTTP 204. Base rejected this batch during whitelist preflight; the underlying reuse already affected unrestricted users. Keep the original connection context unchanged and parse each member into a fresh copy, as the refused-batch helper does. Add cases with a scalar after an identified request and after a notification; the new malformed-member tests only use objects that reset the ID. No current client sending non-object batch members was identified, so production impact is unconfirmed.

Earlier report and explanation. Check its locations and suggested fix against this revision.