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]

No issues found.

I re-reviewed all hunks in this PR (the loosened debug_asserts in on_tx_signatures_exchange at channel.rs:9533-9536, the gating change at channel.rs:9689, the removed reestablish-time expecting_peer_commitment_signed = true at channel.rs:10647, and the new test in splicing_tests.rs). The logic is internally consistent:

• The hold-back guard now only triggers when both is_awaiting_monitor_update() and monitor_pending_tx_signatures hold, correctly allowing the tx_signatures exchange to proceed when only an unrelated monitor update (e.g. an HTLC preimage persist) is pending.
• Both call sites of on_tx_signatures_exchange satisfy the loosened asserts (tx_signatures() only reaches it when the guard is false; monitor_updating_restored clears monitor_pending_tx_signatures at channel.rs:9923 before invoking it).

No new defects beyond my prior pass.

[codecov]

Codecov Report

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

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4748      +/-   ##
==========================================
+ Coverage   84.55%   86.94%   +2.39%     
==========================================
  Files         137      161      +24     
  Lines       77617   111632   +34015     
  Branches    77617   111632   +34015     
==========================================
+ Hits        65627    97064   +31437     
- Misses       9948    12060    +2112     
- Partials     2042     2508     +466     

Flag	Coverage Δ
fuzzing-fake-hashes	8.43% <0.00%> (?)
fuzzing-real-hashes	32.40% <80.00%> (?)
tests	86.27% <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.

[TheBlueMatt]

Not sure I understand this, isn't it the case that we can get a pending monitor update from a preimage no matter the state, so shouldn't we be able to hit this even if we don't have a holder sigs to send? Shouldn't we instead move the monitor_pending_tx_signatures check into the if here?

[TheBlueMatt]

Can you explain this change? Maybe in the commit message?

[wpaulino]

At least according to the docs on expecting_peer_commitment_signed, we were using it incorrectly as it's only meant for channel updates. If it was being used as a signal to disconnect if not sent in a timely manner, then it's unnecessary to track this as we're already quiescent within this path and can rely on that signal instead to disconnect.

[jkczyz]

If holder_tx_signatures is None will we hit the debug_assert in the else clause below on line 9715?

[wpaulino]

I don't think that's reachable because we can't process their tx_signatures without processing their initial commitment_signed first, and we only process that after the user has called back with funding_transaction_signed.

[jkczyz]

@wpaulino Will let you merge in case any of your other PRs conflict.