Skip to content

Check if a batch is expected for commitment_signed #3852

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jun 16, 2025

Conversation

jkczyz
Copy link
Contributor

@jkczyz jkczyz commented Jun 12, 2025

When receiving a commitment_signed message, if there are any pending splices then we are expected to receive the message as a part of a batch. Otherwise, the spec dictates that we should send an error and fail the channel.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jun 12, 2025

👋 Thanks for assigning @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@jkczyz
Copy link
Contributor Author

jkczyz commented Jun 12, 2025

This was caught by @wpaulino post-merge of #3793.

@jkczyz jkczyz requested a review from wpaulino June 12, 2025 17:01
@ldk-reviews-bot
Copy link

👋 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.

jkczyz added 2 commits June 13, 2025 11:39
When receiving a commitment_signed message, if there are any pending
splices then we are expected to receive the message as a part of a
batch. Otherwise, the spec dictates that we should send an error and
fail the channel.
@jkczyz jkczyz force-pushed the 2025-06-start-batch-fix branch from 93e32d0 to d016801 Compare June 13, 2025 16:47
@jkczyz
Copy link
Contributor Author

jkczyz commented Jun 13, 2025

Rebased and added a commit removing #[rustfmt::skip] here and related code, where there isn't much changing / shouldn't be very controversial.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix is fine, but probably we should unify the codepath here - there's no reason we have a separate codepath for single-CS from multi-CS when the multi-CS codepath would work with a single CS just fine.

@TheBlueMatt TheBlueMatt merged commit 3ff0350 into lightningdevkit:main Jun 16, 2025
27 of 28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants