fuzz: cover deferred writing in chanmon_consistency

[joostjager]

Adds fuzz coverage for #4351

[ldk-reviews-bot]

👋 I see @wpaulino was un-assigned.
If you'd like another reviewer assignment, please click here.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.12%. Comparing base (75ac90a) to head (e0c5818).
⚠️ Report is 16 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4465      +/-   ##
==========================================
- Coverage   86.12%   86.12%   -0.01%     
==========================================
  Files         157      157              
  Lines      108824   108944     +120     
  Branches   108824   108944     +120     
==========================================
+ Hits        93727    93826      +99     
- Misses      12480    12499      +19     
- Partials     2617     2619       +2     

Flag	Coverage Δ
tests	86.12% <ø> (-0.01%)	⬇️

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

☔ View full report in Codecov by Sentry.
📢 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.

[joostjager]

Rebased

[joostjager]

Will hold off on this until pre-existing fuzz failures #4496 and #4472 are in

[joostjager]

Prerequisites are in, rebased.

[TheBlueMatt]

This LGTM, why is it draft?

[joostjager]

I first wanted to do a serious local run, but then it turned out there are so many pre-existing fuzz failures that it is hard to see what's new. I've bisected the failures to the various PRs that introduced them.

[joostjager]

Although for this PR I could just see if anything pops up that doesnt repro on main. Will do that.

[joostjager]

Several newly introduced fuzz failures to address:

7084a32219ffa61b1919192119197084a32219ff4400001d228012ffab
10fa0040801170704040198040111911191f1f1170bbff1170ffb3b2b6
10000150804211be707040198011191f1119401f401f0aa97210b6ff25
10000150804211707040198011191f11191f1a4040a91f7210b6ff25

[joostjager]

Zoomed in on one of those sequences, and it seems it is reproducible with another string without deferred mode too.

0270801109191109191f1f10b6ff

[joostjager]

Dependency: #4520

[joostjager]

Interestingly the non-deferred mode reproducer 0270801109191109191f1f10b6ff doesn't fail on main anymore, with #4520 not yet merged. Bisected the fixing PR to #4529 (@tankyleo).

It seems the increased headroom made the bug unobservable to the fuzzer?

I ran the fuzzer on this branch overnight, and no failures were found.

[joostjager]

I'll try to add a new invariant to the fuzzer so it catches the problem in a more robust way.

[joostjager]

Invariant addition: #4601

[joostjager]

Will rebase this after #4571

[ldk-claude-review-bot]

I've carefully re-reviewed the entire PR diff, cross-referencing with the ChainMonitor internals, the flush mechanism, the watch_channel_internal/update_channel_internal paths, and the fuzz loop convergence logic.

All four previously flagged issues remain unaddressed in the current code. No code changes have occurred since the prior review pass.

No new issues found beyond the prior review.

Summary

Previously flagged issues (still open):

1. fuzz/src/chanmon_consistency.rs:367 — Docstring describes snapshot-then-flush pattern, but the implementation encodes the ChannelManager before flushing, so the fuzzer always tests post-flush manager state rather than the more interesting mid-flush crash scenario.

2. fuzz/src/chanmon_consistency.rs:386 — track_monitor_update with Completed status calls mark_persisted which drains pending_monitors for the channel. This relies on the invariant that update_ret never changes during a node's lifetime. The invariant holds today but is not documented and is fragile.

3. fuzz/src/chanmon_consistency.rs:421 — Previously confirmed as a false positive. pending_monitors and pending_monitor_completions are independent lists; pruning restart candidates does not affect completion obligations.

4. fuzz/src/chanmon_consistency.rs:1179 — In reload, the new HarnessPersister is created with self.persistence_style at line 1103, meaning deferred+InProgress nodes get InProgress for startup watch_channel persists during the flush at line 1172. This creates unnecessary completion obligations from startup that don't correspond to a realistic post-restart state.

Cross-cutting observations:

• The settle loop convergence changes (tracking made_progress from checkpoint_manager_persistences and complete_all_monitor_updates, plus the had_events = true fix in process_events) are correct and improve convergence detection for deferred mode.
• The make_channel refactor to use split_at_mut is correct — the assert!(source_idx < dest_idx) guard ensures the split is valid, and the added checkpoint_manager_persistence calls before complete_all_pending_monitor_updates are necessary for deferred mode.
• The separation of pending_monitors (restart candidates) and pending_monitor_completions (ChainMonitor ack obligations) is sound — the two lists intentionally diverge and are pruned independently.

[joostjager]

I reworked this PR and based it on a preparatory commit that makes the fuzzer's persistence model much more understandable, in my opinion. The prep work was taken from the force-close fuzzing PR #4381 that is still WIP, so it should be useful there as well.

[joostjager]

Fuzzed this overnight, no failures other than what is pre-existing in main.