Avoid returning user error when stfu is not ready to be sent yet
What the developer wrote
Authored by Wilmer Paulino
Avoid returning user error when stfu is not ready to be sent yet
When we propose quiescence due to a user initiated action, such as a
splice, it's possible that the `stfu` message is not ready to be sent
out yet due to the state machine pending a change. This would result in
an error communicated back to the caller of
`ChannelManager::splice_channel`, but this is unnecessary and confusing,
the splice is still pending and will be carried out once quiescence is
eventually negotiated.
What changed, and why it matters
This change fixes a minor user-experience issue in the Lightning Dev Kit's channel splicing flow. Previously, if a user requested a splice but the internal state machine wasn't ready to send the required 'stfu' (stop, wait for update) message immediately, the code would return an error to the caller even though the splice was still pending and would proceed later. Now it logs the condition and returns success with no message, avoiding an unnecessary and confusing error.
Review as a normal bugfix. Verify that suppressing the error does not mask any state where the splice should legitimately be aborted, and that the pending splice will reliably resume when quiescence becomes ready. No immediate security response is indicated.
Security signals we found
Change converts an error return into a silent success with debug logging
Affects state-machine handling of the BOLT quiescence `stfu` message
Potential for user-initiated operation to proceed despite an internal condition that previously failed
No input validation, bounds checking, or cryptographic changes present
Evidence from the diff
In lightning/src/ln/channel.rs, the code that initiates channel quiescence for user-initiated actions (e.g., splicing) was changed to swallow errors from send_stfu() when the channel is live but the message cannot yet be sent. Instead of propagating the error to the caller of ChannelManager::splice_channel, it logs the error at debug level and returns Ok(None). The splice remains pending and will be carried out once quiescence is negotiated later. This is a behavioral fix, not a memory-safety or cryptographic fix.
Changed components
lightning/src/ln/channel.rsChannel quiescence / `stfu` message handlingChannelManager::splice_channel user APIInspect captured patch +7 / −1
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index c5942f3..d7acb1a 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -13099,7 +13099,13 @@ where
self.context.channel_state.set_awaiting_quiescence();
if self.context.is_live() {
- Ok(Some(self.send_stfu(logger)?))
+ match self.send_stfu(logger) {
+ Ok(stfu) => Ok(Some(stfu)),
+ Err(e) => {
+ log_debug!(logger, "{e}");
+ Ok(None)
+ },
+ }
} else {
log_debug!(logger, "Waiting for peer reconnection to send stfu");
Ok(None)
Why this scored 21/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.