From a099f5a804e7597b99afb108a7973056fedabee0 Mon Sep 17 00:00:00 2001 From: Bronek Kozicki Date: Tue, 8 Apr 2025 15:43:34 +0100 Subject: [PATCH] Remove UNREACHABLE from `NetworkOPsImp::processTrustedProposal` (#5387) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It’s possible for this to happen legitimately if a set of peers, including a validator, are connected in a cycle, and the latency and message processing time between those peers is significantly less than the latency between the validator and the last peer. It’s unlikely in the real world, but obviously easy to simulate with Antithesis. --- src/xrpld/app/misc/NetworkOPs.cpp | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/xrpld/app/misc/NetworkOPs.cpp b/src/xrpld/app/misc/NetworkOPs.cpp index 0acc5a215d..b72963aa81 100644 --- a/src/xrpld/app/misc/NetworkOPs.cpp +++ b/src/xrpld/app/misc/NetworkOPs.cpp @@ -1936,11 +1936,14 @@ NetworkOPsImp::processTrustedProposal(RCLCxPeerPos peerPos) // is a trusted message, it could be a very big deal. Either way, we // don't want to relay the proposal. Note that the byzantine behavior // detection in handleNewValidation will notify other peers. - UNREACHABLE( - "ripple::NetworkOPsImp::processTrustedProposal : received own " - "proposal"); + // + // Another, innocuous explanation is unusual message routing and delays, + // causing this node to receive its own messages back. JLOG(m_journal.error()) - << "Received a TRUSTED proposal signed with my key from a peer"; + << "Received a proposal signed by MY KEY from a peer. This may " + "indicate a misconfiguration where another node has the same " + "validator key, or may be caused by unusual message routing and " + "delays."; return false; }