[DO NOT REVIEW] fundingManager: Set up channel barrier on startup if fundingLocked is not yet received #309
Conversation
This file contains 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
halseth
changed the title
This commit adds a channel barrier on fundingManager startup for channels that we still haven't received fundingLocked for. This fixes a bug where we after restarting the fundingManager would receive the fundingLocked message, and crash when trying to close the non-existing barrier. The fundingmanager tests are also updated to check that the fundingLocked messages are sent and handled correcly, and also exercise the scanario described above.
halseth
force-pushed
the
funding-locked-test
branch
from
980be7b
to
2bd7027
Compare
|
This change has been included in #328 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
DO NOT REVIEW
Changes
This commit adds a channel barrier on
fundingManagerstartup for channels that we still haven'treceived
fundingLockedfor. This fixes a bug where we after restarting thefundingManagerwould receive thefundingLockedmessage, and crash when trying to close the non-existing barrier.Tests
The
fundingmanagertests are also updated to check that thefundingLockedmessages are sent and handled correctly, and also exercise the scenario described above.Follow-up
There are still cases not handled by the
fundingManager,that will be tested and (hopefully) fixed in follow up PRs.fundingLockedmessage, but fail to announce the channel and send our ownfundingLocked, we'll never process the receivedfundingLocked. In case of a restart, we'll retry our own announcement, but we cannot know for sure that our peer will resend thefundingLocked, causing the channel to never become fully operational. In this case we should keep the state given to us by the receivedfundingLocked.fundingLockedmessages from the peer, we will crash. This happens because we don't have a channel barrier set up (we don't expect to receive a second), and try to close the non-existing barrier.fundingManager. However, we must also continue the process when a peer reestablish the connection: Re-send FundingLocked in ChannelLink upon re-connect if at state zero #303Common for these scenarios is that they arise from the interaction between the received
fundingLockedmessages and the state of our sent messages. Decoupling the state machines of these two will probably simplify this logic.