diff --git a/zebra-network/src/peer/connection.rs b/zebra-network/src/peer/connection.rs index 838f25d1d..7fd535aa9 100644 --- a/zebra-network/src/peer/connection.rs +++ b/zebra-network/src/peer/connection.rs @@ -525,31 +525,20 @@ where .lock() .expect("mutex should be unpoisoned"); if let Some(original_error) = guard.clone() { - // A failed connection might experience further errors if we: - // 1. concurrently process two different messages - // 2. check for a failed state for the second message - // 3. fail the connection due to the first message - // 4. fail the connection due to the second message - // - // It's not clear: - // * if this is actually a bug, - // * how we can modify Zebra to avoid it. - // - // This warning can also happen due to these bugs: + // This panic typically happens due to these bugs: // * we mark a connection as failed without using fail_with // * we call fail_with without checking for a failed connection // state // - // See the original bug #1510, the initial fix #1531, and the later - // bug #1599. - warn!(?original_error, - new_error = ?e, - connection_state = ?self.state, - client_receiver = ?self.client_rx, - "calling fail_with on already-failed connection state: ignoring new error"); - // we don't need to clean up the connection, the original call to - // fail_with does that - return; + // See the original bug #1510 and PR #1531, and the later bug #1599 + // and PR #1600. + panic!( + "calling fail_with on already-failed connection state: failed connections must stop processing pending requests and responses, then close the connection. state: {:?} original error: {:?} new error: {:?} client receiver: {:?}", + self.state, + original_error, + e, + self.client_rx + ); } else { *guard = Some(e); }