Print unexpected events upon assertion failure
What changed, and why it matters
This commit only improves an error message in test helper code. When a test expects exactly one event but gets a different number, the macro now prints the unexpected events for easier debugging. It does not change production behavior or fix any security issue.
No security action needed. Treat as normal test infrastructure improvement.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The change is in lightning/src/ln/functional_test_utils.rs in the get_event! test macro. It replaces a bare assert_eq!(events.len(), 1) with an assert that the vector is non-empty and an assert_eq! that includes a formatted debug message of the events. This is purely a test-debugging quality-of-life improvement; no runtime or consensus code is affected.
Changed components
lightning/src/ln/functional_test_utils.rsget_event! test macroInspect captured patch +2 / −1
diff --git a/lightning/src/ln/functional_test_utils.rs b/lightning/src/ln/functional_test_utils.rs
index 35138c1..82c4ac8 100644
--- a/lightning/src/ln/functional_test_utils.rs
+++ b/lightning/src/ln/functional_test_utils.rs
@@ -1088,7 +1088,8 @@ pub fn get_warning_msg(node: &Node, recipient: &PublicKey) -> msgs::WarningMessa
macro_rules! get_event {
($node: expr, $event_type: path) => {{
let mut events = $node.node.get_and_clear_pending_events();
- assert_eq!(events.len(), 1);
+ assert!(!events.is_empty(), "Expected an event");
+ assert_eq!(events.len(), 1, "Unexpected events {events:?}");
let ev = events.pop().unwrap();
match ev {
$event_type { .. } => ev,
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.