AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 15 Bitcoin

chancloser: stabilize remote RBF coop tests

Public commit record

What the developer wrote

Authored by Boris Nagaev

98/100 · Strong
chancloser: stabilize remote RBF coop tests

CI started panicking in TestRbfChannelFlushingTransitions/early_offer /
TestRbfCloseClosingNegotiationRemote (see GitHub Actions run
https://github.com/lightningnetwork/lnd/actions/runs/19155841408/job/54756127218?pr=10352)
because the cached remote offer could fire before the test harness
registered its mock CloseSigner expectations. When that happened,
the mock complained that CreateCloseProposal was unexpected:

panic:
assert: mock: I don't know what to return because the method call was unexpected.

Fix this by having assertSingleRemoteRbfIteration take a sendEvent callback
that receives the context and initial offer, so tests can install expectations
first and then fire the event via SendEvent (or the early-offer test's custom
flush sender).

Reproduction (on master)
------------------------
1. Modify lnwallet/chancloser/rbf_coop_test.go
Add time.Sleep(10 * time.Millisecond) before the first call of
closeHarness.assertSingleRemoteRbfIteration (in function
TestRbfChannelFlushingTransitions).

2. go test ./lnwallet/chancloser -run TestRbfChannelFlushingTransitions/early_offer

3. The panic reproduces immediately.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a flaky test in LND's cooperative channel-closing code. The test sometimes panicked because an event arrived before the test had finished setting up its mock objects. The change lets tests install mock expectations first and then trigger the event, making the test suite more reliable. It does not change production code or fix a security vulnerability.

Recommended action

No security action needed. Treat as routine test-stability improvement.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 10/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.