lightningd: don't complain if gossipd tells us about dead channel on startup.
What the developer wrote
Authored by Rusty Russell
lightningd: don't complain if gossipd tells us about dead channel on startup.
This can happen if gossipd hasn't processed the blocks yet:
```
lightningd-2 2026-01-07T06:05:19.430Z **BROKEN** 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#3: gossipd gave channel_update in CGOSSIP_CHANNEL_ANNOUNCED_DEAD? update=010240d5d1b653118c047218802d8c5d6bda49124fc9e1cb30ceff72e24c44e6a20d0b6b6fbe5465def31a01c8ff49dc171542a64a1a69d5149698f31e1ba4e721c106226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f00006f0000010000695df63a010200060000000000000000000000010000000a000000003b023380
```
It does catch up later, so ignore this.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit removes a 'BROKEN' log warning that could appear when Core Lightning starts up and receives gossip about a channel that is considered dead. The warning was harmless because the gossip daemon catches up with recent blocks shortly after startup. The change simply stops logging this expected temporary condition as a broken error.
No security action required. This is a log-noise reduction fix for a known transient startup condition. Operators can treat the previously logged BROKEN message as benign if it occurred around startup.
Security signals we found
Removes a BROKEN log assertion for a transient startup state
No privilege escalation, memory corruption, or cryptographic weakness introduced
Behavior change is defensive: avoids false-positive error reporting
Evidence from the diff
In lightningd/channel_gossip.c, the CGOSSIP_CHANNEL_ANNOUNCED_DEAD state was moved out of the group of states treated as ‘shouldn’t happen’ for receiving a channel_update. Previously, receiving a channel_update while in ANNOUNCED_DEAD caused a log_broken() message and then fell through to freeing the update. Now ANNOUNCED_DEAD is handled the same as ANNOUNCED_DYING: silently ignore the update. The commit message explains this occurs when gossipd has not yet processed blocks after a restart and will self-correct.
Changed components
lightningd/channel_gossip.cCGOSSIP_CHANNEL_ANNOUNCED_DEAD state handlingInspect captured patch +3 / −1
diff --git a/lightningd/channel_gossip.c b/lightningd/channel_gossip.c
index d00627a1..01207818 100644
--- a/lightningd/channel_gossip.c
+++ b/lightningd/channel_gossip.c
@@ -1096,13 +1096,15 @@ void channel_gossip_update_from_gossipd(struct channel *channel,
case CGOSSIP_WAITING_FOR_USABLE:
case CGOSSIP_CHANNEL_DEAD:
case CGOSSIP_CHANNEL_UNANNOUNCED_DYING:
- case CGOSSIP_CHANNEL_ANNOUNCED_DEAD:
/* Shouldn't happen. */
log_broken(channel->log,
"gossipd gave channel_update in %s? update=%s",
channel_gossip_state_str(channel->channel_gossip->state),
tal_hex(tmpctx, channel_update));
/* fall thru */
+ /* ANNOUNCED_DEAD can happen is gossipd hadn't processed block
+ * when we restarted; ignore, as it will catch up soon. */
+ case CGOSSIP_CHANNEL_ANNOUNCED_DEAD:
case CGOSSIP_CHANNEL_ANNOUNCED_DYING:
if (taken(channel_update))
tal_free(channel_update);
Why this scored 17/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.