Lower strictness of pending monitor update while awaiting tx_signatures

[wpaulino]

We previously assumed that no monitor update should ever be pending when receiving tx_signatures while quiescent, with the exception of the RenegotiatedFunding variant. This was a bit too strict, as we did not consider that if an HTLC was sent via the same channel, its preimage could be received from upstream leading to a monitor update to durably persist it.

This commit ensures that if the recipient of a tx_signatures has not yet echoed theirs back, and it is awaiting a monitor update completion, then the pending monitor update must be of the RenegotiatedFunding variant. If the pending monitor update is of another variant, then we must remain quiescent with no pending updates available to send until after the tx_signatures exchange.

Fixes #4729.

[ldk-reviews-bot]

👋 Thanks for assigning @jkczyz 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.

[ldk-claude-review-bot]

I've completed a thorough review of all hunks in this PR.

No issues found.

I examined the core logic changes and verified they are internally consistent:

• channel.rs:9533-9536 — The loosened debug_asserts in on_tx_signatures_exchange are correct for all call sites. From monitor_updating_restored, monitor_pending_tx_signatures is set false just before the call (line 9923); from tx_signatures(), the path is only reached when !(awaiting_monitor_update && holder_tx_signatures.is_some()), satisfying the first assert.
• channel.rs:9689 — Adding && holder_tx_signatures.is_some() correctly allows completing the tx_signatures exchange when the holder has already echoed its signatures (so there is nothing to hold back) even while an unrelated monitor update (e.g. an HTLC preimage) is pending. received_tx_signatures returns None here for the party that already sent first, so the guard only short-circuits the send-second party still owing its tx_signatures.
• channel.rs:10647 — Removing the reestablish-time expecting_peer_commitment_signed = true is consistent with the new is_waiting_on_peer_pending_channel_update() assert; it does not regress maybe_propose_closing_signed, since closing_negotiation_ready() already gates on a pending interactive signing session.
• The added test imports (SignerOp) are used, and the helpers it relies on (complete_sole_pending_chan_update, expect_splice_pending_event) exist.

One area worth a maintainer's eye (not a defect I can demonstrate): the retained debug_assert!(self.context.monitor_pending_tx_signatures) at channel.rs:9693 now relies on the invariant that a not-yet-echoed tx_signatures while awaiting a monitor update always implies the RenegotiatedFunding update. This matches the PR's stated reasoning and is only a debug-build assertion, but it is the subtlest correctness assumption in the change.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.95%. Comparing base (6965bc9) to head (c583fa7).
⚠️ Report is 3224 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4748      +/-   ##
==========================================
+ Coverage   84.55%   86.95%   +2.40%     
==========================================
  Files         137      161      +24     
  Lines       77617   111632   +34015     
  Branches    77617   111632   +34015     
==========================================
+ Hits        65627    97073   +31446     
- Misses       9948    12055    +2107     
- Partials     2042     2504     +462     

Flag	Coverage Δ
fuzzing-fake-hashes	8.43% <0.00%> (?)
fuzzing-real-hashes	32.40% <75.00%> (?)
tests	86.28% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.