Revert "Stop panicking when fail_with is called twice on a connection"

But keep the extra error information.
This commit is contained in:
teor 2021-01-18 14:53:23 +10:00 committed by Deirdre Connolly
parent 4fe81da953
commit 05fff8e6f7
1 changed files with 10 additions and 21 deletions

View File

@ -525,31 +525,20 @@ where
.lock() .lock()
.expect("mutex should be unpoisoned"); .expect("mutex should be unpoisoned");
if let Some(original_error) = guard.clone() { if let Some(original_error) = guard.clone() {
// A failed connection might experience further errors if we: // This panic typically happens due to these bugs:
// 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:
// * we mark a connection as failed without using fail_with // * we mark a connection as failed without using fail_with
// * we call fail_with without checking for a failed connection // * we call fail_with without checking for a failed connection
// state // state
// //
// See the original bug #1510, the initial fix #1531, and the later // See the original bug #1510 and PR #1531, and the later bug #1599
// bug #1599. // and PR #1600.
warn!(?original_error, panic!(
new_error = ?e, "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: {:?}",
connection_state = ?self.state, self.state,
client_receiver = ?self.client_rx, original_error,
"calling fail_with on already-failed connection state: ignoring new error"); e,
// we don't need to clean up the connection, the original call to self.client_rx
// fail_with does that );
return;
} else { } else {
*guard = Some(e); *guard = Some(e);
} }