Test channel reestablish during splice lifecycle #4079
Conversation
|
👋 Thanks for assigning @jkczyz as a reviewer! |
|
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 3rd Reminder Hey @jkczyz! This PR has been waiting for your review. |
wpaulino
force-pushed
the
test-splice-reestablish
branch
from
aa5ab88 to
e841721
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4079 +/- ##
==========================================
+ Coverage 88.53% 88.66% +0.13%
==========================================
Files 179 179
Lines 134413 134717 +304
Branches 134413 134717 +304
==========================================
+ Hits 119002 119451 +449
+ Misses 12653 12507 -146
- Partials 2758 2759 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Needs rebase :( |
We may produce duplicate `FundingTransactionReadyForSigning` events if the user has processed an initial event but has not yet called back with `funding_transaction_signed` and a peer reconnection occurs. If the user also handles the duplicate events, any duplicate calls to `funding_transaction_signed` after an initial successful one would return an error. This doesn't make sense, as the API should remain idempotent, so we return early on any duplicate calls.
As per the spec requirement, this was already enforced throughout the happy case when a disconnection does not happen. If a disconnect would happen, we always naively cleared the flag without checking whether we did indeed exchange `tx_signatures`.
We only want to produce `tx_signatures` once we know that the monitor update (either the initial one for a dual-funded channel, or a `RenegotiatedFunding` one for a splice) has been persisted. If we haven't received the counterparty's `commitment_signed` yet, then the monitor update hasn't been created, leading us to pass the `!awaiting_monitor_update` condition and produce a holder `tx_signatures` message.
We'll use this in the next commit to test the resend logic for `announcement_signatures` when reestablishing a channel that had a pending splice become locked.
This test captures all the new spec requirements introduced for a splice to the channel reestablish flow.
wpaulino
force-pushed
the
test-splice-reestablish
branch
from
e841721 to
9588403
Compare
| if signing_session.holder_tx_signatures().is_some() { | ||
| // Our `tx_signatures` either should've been the first time we processed them, | ||
| // or we're waiting for our counterparty to send theirs first. | ||
| return Ok((None, None)); | ||
| } |
There was a problem hiding this comment.
Is it possible to hit the error below (i.e. when there is no signing session) if a duplicate event is processed?
There was a problem hiding this comment.
Hm, yeah they would. Not sure what else we can do here though if they're genuinely calling this at the wrong time? We'll keep the session around until channel_ready/splice_locked so maybe we can also avoid returning an error if funding_txid_signed == self.funding.get_funding_txid()?
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
This also includes a couple small bug fixes found along the way.