[DO NOT REVIEW] fundingManager: Set up channel barrier on startup if fundingLocked is not yet received #309
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
fundingManager
startup for channels that we still haven'treceived
fundingLocked
for. This fixes a bug where we after restarting thefundingManager
would receive thefundingLocked
message, and crash when trying to close the non-existing barrier.Tests
The
fundingmanager
tests are also updated to check that thefundingLocked
messages 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.fundingLocked
message, 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
.fundingLocked
messages 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
fundingLocked
messages and the state of our sent messages. Decoupling the state machines of these two will probably simplify this logic.