Correct `test_dup_htlc_onchain_doesnt_fail_on_reload`
What the developer wrote
Authored by Matt Corallo
Correct `test_dup_htlc_onchain_doesnt_fail_on_reload`
`test_dup_htlc_onchain_doesnt_fail_on_reload` made reference to
`ChainMonitor` persisting `ChannelMonitor`s on each new block,
which hasn't been the case in some time. Instead, we update the
comment and code to make explicit that it doesn't impact the test.
What changed, and why it matters
This commit only updates an internal test and its comments. It removes an outdated assumption that a component called ChainMonitor saves ChannelMonitors on every new block, and instead makes clear that the test does not rely on that behavior. There is no change to production code, no fix for a security issue, and no security relevance stated by the project.
No security action needed. This is a routine test-maintenance commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff modifies a single Rust test file, lightning/src/ln/payment_tests.rs. It removes an unused import (ChannelMonitorUpdateStatus) and removes a line that simulated a persistent-update-in-progress status during the test. It updates the comment to explain that ChannelMonitors are not re-persisted per block connection, and adds a check_added_monitors(&nodes[0], 0) assertion to verify no new monitor updates were produced. The production logic under test is unchanged.
Changed components
lightning/src/ln/payment_tests.rsInspect captured patch +5 / −6
diff --git a/lightning/src/ln/payment_tests.rs b/lightning/src/ln/payment_tests.rs
index 67c7599..0af0463 100644
--- a/lightning/src/ln/payment_tests.rs
+++ b/lightning/src/ln/payment_tests.rs
@@ -14,7 +14,7 @@
use crate::chain::channelmonitor::{
ANTI_REORG_DELAY, HTLC_FAIL_BACK_BUFFER, LATENCY_GRACE_PERIOD_BLOCKS,
};
-use crate::chain::{ChannelMonitorUpdateStatus, Confirm, Listen};
+use crate::chain::{Confirm, Listen};
use crate::events::{
ClosureReason, Event, HTLCHandlingFailureType, PathFailure, PaymentFailureReason,
PaymentPurpose,
@@ -1310,16 +1310,15 @@ fn do_test_dup_htlc_onchain_doesnt_fail_on_reload(
connect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
}
- // Now connect the HTLC claim transaction with the ChainMonitor-generated ChannelMonitor update
- // returning InProgress. This should cause the claim event to never make its way to the
- // ChannelManager.
- chanmon_cfgs[0].persister.set_update_ret(ChannelMonitorUpdateStatus::InProgress);
-
+ // Now connect the HTLC claim transaction. Note that ChannelMonitors aren't re-persisted on
+ // each block connection (as the block being reconnected on startup should get us the same
+ // result).
if payment_timeout {
connect_blocks(&nodes[0], 1);
} else {
connect_block(&nodes[0], &claim_block);
}
+ check_added_monitors(&nodes[0], 0);
// Note that we skip persisting ChannelMonitors. We should still be generating the payment sent
// event without ChannelMonitor persistence. If we reset to a previous state on reload, the block
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.