itest fix flake in revokedCloseRetributionRemoteHodlCase #10460
Conversation
Summary of ChangesHello @ziggie1984, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
b409c7d to
9b62490
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request addresses a flaky test by changing the waiting logic in CompletePaymentRequestsNoWait to count pending HTLCs instead of relying on NumUpdates. The approach is a clear improvement. My review includes suggestions to make the waiting condition even more robust by checking if the HTLCs are fully 'locked in', which would also align the implementation more closely with the guarantee mentioned in the pull request description. This will further improve the reliability of tests that depend on this function.
There was a problem hiding this comment.
Code Review
This pull request effectively addresses a race condition in CompletePaymentRequestsNoWait by shifting the waiting mechanism from monitoring NumUpdates to counting the number of newly added outgoing HTLCs. This change provides a more reliable way to ensure all payments are committed before proceeding, fixing the described test flakiness. The implementation is clear and correct. I have one minor suggestion to refactor a small piece of duplicated logic for better maintainability.
9b62490 to
e849989
Compare
Before this change, CompletePaymentRequestsNoWait would return as soon as the channel's NumUpdates increased by at least one. When sending multiple payments, this meant the function could return while some HTLCs were still in-flight and not yet committed to the channel state. The problem occurred when tests captured the channel state immediately after calling this function. Even though we read the current NumUpdates from the channel, HTLCs could still be in the process of being committed. This led to a race where the channel would progress to a new state after we thought we had correctly captured it, causing tests to see unexpected commitment heights. Fix this by waiting for all outgoing HTLCs to appear in PendingHtlcs before returning. We count outgoing HTLCs before sending, then wait until exactly len(paymentRequests) new HTLCs are present. This guarantees all payments have fully completed their commitment exchange and are locked in on both sides. Fixes the flaky revokedCloseRetributionRemoteHodlCase test where backups would capture state at height N+1 instead of the expected height N.
e849989 to
ece8469
Compare
Fixes a common seen flake see also here: https://github.com/lightningnetwork/lnd/actions/runs/20314774459/job/58355291404?pr=10049
Did catch our attention because the retribution test failed, however everything is fine with this logic. There core issue was that we would not wait for all HTLCs to properly lockin and then after capturing the state the channel would still try to progress the channel state to commit all inflight HTLCs.