funding: fix race in itest for zero-conf funding#10440
Merged
ziggie1984 merged 1 commit intolightningnetwork:masterfrom Dec 11, 2025
Merged
funding: fix race in itest for zero-conf funding#10440ziggie1984 merged 1 commit intolightningnetwork:masterfrom
ziggie1984 merged 1 commit intolightningnetwork:masterfrom
Conversation
ziggie1984
added
no-changelog
itests
ziggie1984
force-pushed
the
bugfix/itest-race
branch
from
5f8b968 to
8711276
Compare
Fix a race condition where forwarding through a public zero-conf channel could fail with UnknownNextPeer when using the confirmed SCID. The issue occurred because ReportShortChanID (which updates the switch's baseIndex to handle the confirmed SCID) was called AFTER addToGraph (which announces the confirmed SCID to the network). With slow backends like postgres, addToGraph takes significant time, creating a window where other nodes learn about the confirmed SCID from gossip and attempt to route through it, but the receiving node's switch hasn't been updated yet to handle forwards using the confirmed SCID. The fix reorders operations to call ReportShortChanID before addToGraph, ensuring the switch is ready to handle the confirmed SCID before it's announced to the network. Forwards using either the alias or confirmed SCID will work since getLinkByMapping uses baseIndex to map both to the same link in forwardingIndex. Fixes flaky test: zero_conf-channel_policy_update_public_zero_conf
ziggie1984
force-pushed
the
bugfix/itest-race
branch
from
8711276 to
fe9a3e1
Compare
starius
approved these changes
Dec 11, 2025
Collaborator
starius
left a comment
starius
left a comment
There was a problem hiding this comment.
LGTM! 🏆
Thanks for fixing this! The test is wonderful - it serves as a regression test.
Just one comment: if ReportShortChanID fails because of a transient DB error, does it make sense to call addToGraph?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix a race condition where forwarding through a public zero-conf channel
could fail with UnknownNextPeer when using the confirmed SCID. The issue
occurred because ReportShortChanID (which updates the switch's baseIndex
to handle the confirmed SCID) was called AFTER addToGraph (which announces
the confirmed SCID to the network).
With slow backends like postgres, addToGraph takes significant time,
creating a window where other nodes learn about the confirmed SCID from
gossip and attempt to route through it, but the receiving node's switch
hasn't been updated yet to handle forwards using the confirmed SCID.
The fix reorders operations to call ReportShortChanID before addToGraph,
ensuring the switch is ready to handle the confirmed SCID before it's
announced to the network. Forwards using either the alias or confirmed
SCID will work since getLinkByMapping uses baseIndex to map both to the
same link in forwardingIndex.
Fixes flaky test: zero_conf-channel_policy_update_public_zero_conf
Fix #9912