Skip to content

Commit 135f414

Browse files
committed
Stop persisting background shutdown monitor updates
In d481008 we added logic to apply `ChannelMonitorUpdate`s which were a part of a channel closure async via a background queue to address some startup issues. When we did that we persisted those updates to ensure we replayed them when starting next time. However, there was no reason to - if we persisted and then restarted even without those monitor updates we'd find a monitor without a channel, which we'd tell to broadcast the latest commitment transaction to force-close. Since adding that logic, we've used the same background queue for several purposes.
1 parent f569e9f commit 135f414

File tree

1 file changed

+11
-18
lines changed

1 file changed

+11
-18
lines changed

lightning/src/ln/channelmanager.rs

Lines changed: 11 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -7448,17 +7448,12 @@ where
74487448
}
74497449
}
74507450

7451-
let background_events = self.pending_background_events.lock().unwrap();
7452-
(background_events.len() as u64).write(writer)?;
7453-
for event in background_events.iter() {
7454-
match event {
7455-
BackgroundEvent::ClosingMonitorUpdate((funding_txo, monitor_update)) => {
7456-
0u8.write(writer)?;
7457-
funding_txo.write(writer)?;
7458-
monitor_update.write(writer)?;
7459-
},
7460-
}
7461-
}
7451+
// LDK versions prior to 0.0.116 wrote the `pending_background_events`
7452+
// `ClosingMonitorUpdate`s here, however there was never a reason to do so - the closing
7453+
// monitor updates were always effectively replayed on startup (either directly by calling
7454+
// `broadcast_latest_holder_commitment_txn` on a `ChannelMonitor` during deserialization
7455+
// or, in 0.0.115, by regenerating the monitor update itself).
7456+
0u64.write(writer)?;
74627457

74637458
// Prior to 0.0.111 we tracked node_announcement serials here, however that now happens in
74647459
// `PeerManager`, and thus we simply write the `highest_seen_timestamp` twice, which is
@@ -7905,13 +7900,11 @@ where
79057900
for _ in 0..background_event_count {
79067901
match <u8 as Readable>::read(reader)? {
79077902
0 => {
7908-
let (funding_txo, monitor_update): (OutPoint, ChannelMonitorUpdate) = (Readable::read(reader)?, Readable::read(reader)?);
7909-
if pending_background_events.iter().find(|e| {
7910-
let BackgroundEvent::ClosingMonitorUpdate((pending_funding_txo, pending_monitor_update)) = e;
7911-
*pending_funding_txo == funding_txo && *pending_monitor_update == monitor_update
7912-
}).is_none() {
7913-
pending_background_events.push(BackgroundEvent::ClosingMonitorUpdate((funding_txo, monitor_update)));
7914-
}
7903+
// LDK versions prior to 0.0.116 wrote pending `ClosingMonitorUpdate`s here,
7904+
// however we really don't (and never did) need them - we regenerate all
7905+
// on-startup monitor updates.
7906+
let _: OutPoint = Readable::read(reader)?;
7907+
let _: ChannelMonitorUpdate = Readable::read(reader)?;
79157908
}
79167909
_ => return Err(DecodeError::InvalidValue),
79177910
}

0 commit comments

Comments
 (0)