Remove legacy forwarded message v1/v2 receive handling

[Amaury Chamayou (achamayou)]

Motivation

Coverage run (main @ 854b655) shows src/node/rpc/forwarder.h at 65.8% line coverage. About 64 of its missed lines are the receive paths for the legacy forwarded-message wire formats v1 and v2, which no supported peer can send. v3 (session consistency info) has been emitted since 4.0 (#4595), and the compatibility policy only supports mixed-version operation with the previous LTS (6.x), which always emits v3. The v1/v2 receive paths in Forwarder::recv_message are therefore unreachable and untestable dead code.

Implementation summary

• Removed the forwarded_cmd_v1 and forwarded_cmd_v2 command-handling blocks from Forwarder::recv_message (src/node/rpc/forwarder.h).
• Simplified the response handling to a single forwarded_response_v3 case: cancel the pending timeout task, call recv_forwarded_response<ForwardedResponseHeader_v3>, and reply as before. Removed the v1/v2/v3 if/else header-selection chain and the previous fall-through between response cases.
• Added an explicit case for the four legacy ForwardedMsg values (forwarded_cmd_v1, forwarded_response_v1, forwarded_cmd_v2, forwarded_response_v2) that logs at LOG_FAIL_FMT that the format is no longer supported and drops the message, rather than falling through to the generic default: "unknown type" case.
• Updated the comments on the ForwardedMsg enum in src/node/node_types.h to note that v1/v2 are no longer accepted on receive.
• Kept the ForwardedMsg enum values and the ForwardedHeader_v1/ForwardedHeader_v2 structs unchanged, since ForwardedCommandHeader_v3/ForwardedResponseHeader_v3 inherit from them and src/node/rpc/test/frontend_test.cpp still exercises those headers directly via the templated recv_forwarded_command helper (not through recv_message), so no test changes were needed.
• Added a CHANGELOG.md entry under the existing ### Removed heading for the unreleased [7.0.17] section.

Safety and compatibility

• The ForwardedMsg wire enum values are unchanged (v1=0, response_v1=1, v2=2, response_v2=3, v3=4, response_v3=5), so on-wire framing is unaffected; only the receive-side handling for v1/v2 is removed.
• v3 has been emitted by all supported releases since CCF 4.0, and the compatibility policy only guarantees mixed-version operation with the immediately preceding LTS (6.x), which emits v3. A node on this branch can therefore no longer forward to/from a peer stuck on pre-4.0 behaviour, but such peers were already outside the supported compatibility window.
• Legacy messages that somehow arrive are now logged and dropped instead of processed, avoiding any silent misbehaviour; this is a deliberate behaviour change, documented in the changelog.
• Verified with the full local test suite: unit tests (ctest -L unit, including frontend_test/node_frontend_test) and the e2e_logging end-to-end test, which exercises real backup-to-primary request forwarding over the v3 path, all pass.

[Copilot]

Copilot review overview

🟡 Changes recommended

Add the requested regression test and pull request reference.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Add regression coverage for legacy receive-side rejection · New
• Add pull request reference to changelog entry · New

What changed in this PR

Removes receive-side handling for legacy forwarded-message v1/v2 formats while retaining v3 compatibility.

Changes:

• Drops and logs legacy v1/v2 messages.
• Simplifies forwarding response handling to v3.
• Documents the compatibility change and updates the changelog.

File	Summary	Findings
src/​node/​rpc/​forwarder.h	Removes legacy dispatch and retains v3 handling.	Moderate (2 votes): Add regression coverage through recv_message for dropped legacy messages.
src/​node/​node_types.h	Documents v1/v2 receive incompatibility.	None.
CHANGELOG.md	Records the legacy handling removal.	Nit (3 votes): Append (#8426) to the entry.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.