Also reset notification cooldown on peer disconnection
What the developer wrote
Authored by Elias Rohrer
Also reset notification cooldown on peer disconnection
If we happened to send a notification while the client is connected to
us, we would previously only reset the cooldown once the client connects
again.
While theoretically it would be preferable to never set the
`last_notification_sent` field to begin with if the client is connected
to us, allowing the service handler to query the peer connection state
would be unnecessarily complex. Here, we therefore simply opt to also
reset the `last_notification_sent` state once the peer disconnects from
us.
What changed, and why it matters
This patch fixes a logic bug in how webhook notifications are paced. Previously, if a notification was sent while a client was connected, the system would wait for the client to reconnect before resetting the cooldown timer. If the client disconnected right after the notification, the cooldown could block future notifications from being sent promptly. The fix now resets the cooldown when the peer disconnects, so notifications can resume on schedule.
Review whether any other LSPS service handlers or notification subsystems have similar cooldown state that is not reset on peer disconnection. Consider adding tests covering the disconnect/reconnect sequence for webhook notifications. No immediate emergency action is indicated.
Security signals we found
Timing/state bug in notification cooldown logic
Peer lifecycle event not previously handled for LSPS5 service handler
Potential denial-of-service or notification delay for liquidity clients
Evidence from the diff
In the LSPS5 service handler, last_notification_sent tracks when a webhook notification was last dispatched to enforce a cooldown between notifications. Before this commit, that timestamp was only cleared when the peer reconnected. If a notification was sent while the peer was connected and the peer then disconnected, the cooldown persisted across the disconnection, potentially delaying the next notification until reconnection occurred. The patch adds a peer_disconnected hook that clears last_notification_sent for all webhooks belonging to the disconnecting counterparty, and wires it into the liquidity manager’s existing peer-disconnection path alongside the LSPS2 handler.
Changed components
lightning-liquidity/src/lsps5/service.rslightning-liquidity/src/manager.rsLSPS5ServiceHandler webhook notification cooldown stateInspect captured patch +13 / −0
diff --git a/lightning-liquidity/src/lsps5/service.rs b/lightning-liquidity/src/lsps5/service.rs
index e956ebe..5d492ff 100644
--- a/lightning-liquidity/src/lsps5/service.rs
+++ b/lightning-liquidity/src/lsps5/service.rs
@@ -526,6 +526,15 @@ where
}
}
}
+
+ pub(crate) fn peer_disconnected(&self, counterparty_node_id: &PublicKey) {
+ let mut webhooks = self.webhooks.lock().unwrap();
+ if let Some(client_webhooks) = webhooks.get_mut(counterparty_node_id) {
+ for webhook in client_webhooks.values_mut() {
+ webhook.last_notification_sent = None;
+ }
+ }
+ }
}
impl<CM: Deref, NS: Deref, TP: Deref> LSPSProtocolMessageHandler for LSPS5ServiceHandler<CM, NS, TP>
diff --git a/lightning-liquidity/src/manager.rs b/lightning-liquidity/src/manager.rs
index 6452bd3..835cc9d 100644
--- a/lightning-liquidity/src/manager.rs
+++ b/lightning-liquidity/src/manager.rs
@@ -712,6 +712,10 @@ where
if let Some(lsps2_service_handler) = self.lsps2_service_handler.as_ref() {
lsps2_service_handler.peer_disconnected(counterparty_node_id);
}
+
+ if let Some(lsps5_service_handler) = self.lsps5_service_handler.as_ref() {
+ lsps5_service_handler.peer_disconnected(&counterparty_node_id);
+ }
}
fn peer_connected(
&self, counterparty_node_id: bitcoin::secp256k1::PublicKey, _: &lightning::ln::msgs::Init,
Why this scored 35/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.