Tolerate stale STFU warnings in chanmon fuzz
What the developer wrote
Authored by Joost Jager
Tolerate stale STFU warnings in chanmon fuzz
When stale message events are delivered after a channel close, the
recipient can respond with the expected STFU warning instead of the
control error path. Treat that warning as expected for channels the
harness already tracks closed, while documenting that stale events
should still be delivered so handlers exercise their normal error paths.
What changed, and why it matters
This commit changes only a fuzzing test harness (a tool that randomly exercises code to find bugs). It teaches the test harness to accept a specific warning message as expected when a test delivers an outdated 'STFU' message after a channel is already closed. It does not change the actual Lightning protocol handling code, so it cannot directly affect real users or funds.
No action needed; this is a test-only change. Continue normal review and fuzzing workflows.
Security signals we found
Fuzz harness adjustment only
No production protocol logic changed
Comment explicitly states stale events are still delivered to exercise normal error paths
Evidence from the diff
The diff modifies fuzz/src/chanmon_consistency.rs. It adds a branch in assert_disconnect_action to treat ErrorAction::SendWarningMessage as expected when the warning is for a channel already tracked as closed and the warning text is ‘Peer sent stfu when we were not in a live state’. It also adds a helper is_expected_closed_channel_warning_msg and a comment explaining that stale events are intentionally still delivered so message handlers exercise normal error paths. No production code paths are altered.
Changed components
fuzz/src/chanmon_consistency.rsInspect captured patch +15 / −0
diff --git a/fuzz/src/chanmon_consistency.rs b/fuzz/src/chanmon_consistency.rs
index dfd1b4a..5501489 100644
--- a/fuzz/src/chanmon_consistency.rs
+++ b/fuzz/src/chanmon_consistency.rs
@@ -969,6 +969,14 @@ fn assert_disconnect_action<'a>(
);
ExpectedControlAction::Error(msg)
},
+ msgs::ErrorAction::SendWarningMessage { ref msg, .. } => {
+ assert!(
+ close_tracker.is_expected_closed_channel_warning_msg(msg),
+ "Expected closed-channel warning, got: {:?}",
+ msg,
+ );
+ ExpectedControlAction::Warning(msg, false)
+ },
_ => panic!("Expected harness control error, got: {:?}", action),
}
}
@@ -1044,6 +1052,11 @@ impl ChannelCloseTracker {
== "Peer sent an invalid channel_reestablish to force close in a non-standard way"
|| msg.data.contains("when we needed a channel_reestablish")
}
+
+ fn is_expected_closed_channel_warning_msg(&self, msg: &msgs::WarningMessage) -> bool {
+ self.closed_channels.contains_key(&msg.channel_id)
+ && msg.data == "Peer sent `stfu` when we were not in a live state"
+ }
}
#[derive(Clone, Copy, PartialEq)]
@@ -3080,6 +3093,8 @@ impl<'a, Out: Output + MaybeSend + MaybeSync> Harness<'a, Out> {
corrupt_forward: bool, limit_events: ProcessMessages, nodes: &[HarnessNode<'_>; 3],
close_tracker: &ChannelCloseTracker, out: &Out,
) -> Option<MessageSendEvent> {
+ // Always deliver message events, even when the harness knows they are stale,
+ // so message handlers exercise their normal error paths.
match event {
MessageSendEvent::UpdateHTLCs { node_id, channel_id, updates } => {
handle_update_htlcs_event(
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.