Move ChannelMonitorUpdateStatus mode check from ChannelManager to ChainMonitor by joostjager · Pull Request #4435 · lightningdevkit/rust-lightning

joostjager · 2026-02-23T11:08:46Z

When ChannelMonitor::update_monitor fails (e.g. a counterparty commitment_signed arrives after funding was spent), ChainMonitor persists the full monitor successfully but overrides the return value to InProgress. If the user's Persist impl only returns Completed, this causes ChannelManager::handle_monitor_update_res to panic on the mode mismatch.

The root cause is that the mode check lived in ChannelManager, which sees the post-override status. By moving the check to ChainMonitor and running it against the rawPersist result (before the update_res.is_err() override), we validate only the user's persister behavior. ChainMonitor's internal override to InProgress for failed monitor updates no longer triggers a false mode violation.

ldk-reviews-bot · 2026-02-23T11:08:49Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

…inMonitor When `ChannelMonitor::update_monitor` fails (e.g. a counterparty `commitment_signed` arrives after funding was spent), `ChainMonitor` persists the full monitor successfully but overrides the return value to `InProgress`. If the user's `Persist` impl only returns `Completed`, this causes `ChannelManager::handle_monitor_update_res` to panic on the mode mismatch. The root cause is that the mode check lived in `ChannelManager`, which sees the *post-override* status. By moving the check to `ChainMonitor` and running it against the *raw* `Persist` result (before the `update_res.is_err()` override), we validate only the user's persister behavior. ChainMonitor's internal override to `InProgress` for failed monitor updates no longer triggers a false mode violation. Also fix the `chanmon_consistency` fuzzer's `reload_node`, which hardcoded the persister to `Completed` before calling `watch_channel`, then switched to the node's actual mode afterward. With the mode check now in `ChainMonitor`, this caused a false violation. Set the persister to the correct mode before calling `watch_channel` so `ChainMonitor` sees a consistent persist mode from the start. Additionally, mirror pending monitor updates into `TestChainMonitor.latest_monitors` after `watch_channel` returns `InProgress`. The real `ChainMonitor` tracks the initial `update_id` as pending, but `TestChainMonitor` was unaware of it since `watch_channel` is called on the real `ChainMonitor` directly (bypassing `TestChainMonitor`). Without this, `complete_all_monitor_updates` could never drain and complete the update, leaving reloaded node channels permanently stuck. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

codecov · 2026-02-23T17:03:47Z

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.86%. Comparing base (2d2151a) to head (7e0a4dc).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/chainmonitor.rs	72.22%	5 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4435 +/- ##
==========================================
- Coverage 85.86% 85.86% -0.01% 
==========================================
Files 159 159 Lines 104302 104308 +6 Branches 104302 104308 +6 ==========================================
+ Hits 89558 89563 +5 + Misses 12246 12242 -4 - Partials 2498 2503 +5

Flag	Coverage Δ
tests	`85.86% <73.68%> (-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 · 2026-02-24T10:20:23Z

Closing in favor of alternative fix: #4436

joostjager · 2026-02-23T11:08:46Z

When ChannelMonitor::update_monitor fails (e.g. a counterparty commitment_signed arrives after funding was spent), ChainMonitor persists the full monitor successfully but overrides the return value to InProgress. If the user's Persist impl only returns Completed, this causes ChannelManager::handle_monitor_update_res to panic on the mode mismatch.

The root cause is that the mode check lived in ChannelManager, which sees the post-override status. By moving the check to ChainMonitor and running it against the rawPersist result (before the update_res.is_err() override), we validate only the user's persister behavior. ChainMonitor's internal override to InProgress for failed monitor updates no longer triggers a false mode violation.

ldk-reviews-bot · 2026-02-23T11:08:49Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

…inMonitor When `ChannelMonitor::update_monitor` fails (e.g. a counterparty `commitment_signed` arrives after funding was spent), `ChainMonitor` persists the full monitor successfully but overrides the return value to `InProgress`. If the user's `Persist` impl only returns `Completed`, this causes `ChannelManager::handle_monitor_update_res` to panic on the mode mismatch. The root cause is that the mode check lived in `ChannelManager`, which sees the *post-override* status. By moving the check to `ChainMonitor` and running it against the *raw* `Persist` result (before the `update_res.is_err()` override), we validate only the user's persister behavior. ChainMonitor's internal override to `InProgress` for failed monitor updates no longer triggers a false mode violation. Also fix the `chanmon_consistency` fuzzer's `reload_node`, which hardcoded the persister to `Completed` before calling `watch_channel`, then switched to the node's actual mode afterward. With the mode check now in `ChainMonitor`, this caused a false violation. Set the persister to the correct mode before calling `watch_channel` so `ChainMonitor` sees a consistent persist mode from the start. Additionally, mirror pending monitor updates into `TestChainMonitor.latest_monitors` after `watch_channel` returns `InProgress`. The real `ChainMonitor` tracks the initial `update_id` as pending, but `TestChainMonitor` was unaware of it since `watch_channel` is called on the real `ChainMonitor` directly (bypassing `TestChainMonitor`). Without this, `complete_all_monitor_updates` could never drain and complete the update, leaving reloaded node channels permanently stuck. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

codecov · 2026-02-23T17:03:47Z

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.86%. Comparing base (2d2151a) to head (7e0a4dc).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/chainmonitor.rs	72.22%	5 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4435 +/- ##
==========================================
- Coverage 85.86% 85.86% -0.01% 
==========================================
Files 159 159 Lines 104302 104308 +6 Branches 104302 104308 +6 ==========================================
+ Hits 89558 89563 +5 + Misses 12246 12242 -4 - Partials 2498 2503 +5

Flag	Coverage Δ
tests	`85.86% <73.68%> (-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 · 2026-02-24T10:20:23Z

Closing in favor of alternative fix: #4436

joostjager · 2026-02-23T11:08:46Z

When ChannelMonitor::update_monitor fails (e.g. a counterparty commitment_signed arrives after funding was spent), ChainMonitor persists the full monitor successfully but overrides the return value to InProgress. If the user's Persist impl only returns Completed, this causes ChannelManager::handle_monitor_update_res to panic on the mode mismatch.

The root cause is that the mode check lived in ChannelManager, which sees the post-override status. By moving the check to ChainMonitor and running it against the rawPersist result (before the update_res.is_err() override), we validate only the user's persister behavior. ChainMonitor's internal override to InProgress for failed monitor updates no longer triggers a false mode violation.

ldk-reviews-bot · 2026-02-23T11:08:49Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

…inMonitor When `ChannelMonitor::update_monitor` fails (e.g. a counterparty `commitment_signed` arrives after funding was spent), `ChainMonitor` persists the full monitor successfully but overrides the return value to `InProgress`. If the user's `Persist` impl only returns `Completed`, this causes `ChannelManager::handle_monitor_update_res` to panic on the mode mismatch. The root cause is that the mode check lived in `ChannelManager`, which sees the *post-override* status. By moving the check to `ChainMonitor` and running it against the *raw* `Persist` result (before the `update_res.is_err()` override), we validate only the user's persister behavior. ChainMonitor's internal override to `InProgress` for failed monitor updates no longer triggers a false mode violation. Also fix the `chanmon_consistency` fuzzer's `reload_node`, which hardcoded the persister to `Completed` before calling `watch_channel`, then switched to the node's actual mode afterward. With the mode check now in `ChainMonitor`, this caused a false violation. Set the persister to the correct mode before calling `watch_channel` so `ChainMonitor` sees a consistent persist mode from the start. Additionally, mirror pending monitor updates into `TestChainMonitor.latest_monitors` after `watch_channel` returns `InProgress`. The real `ChainMonitor` tracks the initial `update_id` as pending, but `TestChainMonitor` was unaware of it since `watch_channel` is called on the real `ChainMonitor` directly (bypassing `TestChainMonitor`). Without this, `complete_all_monitor_updates` could never drain and complete the update, leaving reloaded node channels permanently stuck. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

codecov · 2026-02-23T17:03:47Z

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.86%. Comparing base (2d2151a) to head (7e0a4dc).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/chainmonitor.rs	72.22%	5 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4435 +/- ##
==========================================
- Coverage 85.86% 85.86% -0.01% 
==========================================
Files 159 159 Lines 104302 104308 +6 Branches 104302 104308 +6 ==========================================
+ Hits 89558 89563 +5 + Misses 12246 12242 -4 - Partials 2498 2503 +5

Flag	Coverage Δ
tests	`85.86% <73.68%> (-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 · 2026-02-24T10:20:23Z

Closing in favor of alternative fix: #4436

joostjager · 2026-02-23T11:08:46Z

When ChannelMonitor::update_monitor fails (e.g. a counterparty commitment_signed arrives after funding was spent), ChainMonitor persists the full monitor successfully but overrides the return value to InProgress. If the user's Persist impl only returns Completed, this causes ChannelManager::handle_monitor_update_res to panic on the mode mismatch.

The root cause is that the mode check lived in ChannelManager, which sees the post-override status. By moving the check to ChainMonitor and running it against the rawPersist result (before the update_res.is_err() override), we validate only the user's persister behavior. ChainMonitor's internal override to InProgress for failed monitor updates no longer triggers a false mode violation.

ldk-reviews-bot · 2026-02-23T11:08:49Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

…inMonitor When `ChannelMonitor::update_monitor` fails (e.g. a counterparty `commitment_signed` arrives after funding was spent), `ChainMonitor` persists the full monitor successfully but overrides the return value to `InProgress`. If the user's `Persist` impl only returns `Completed`, this causes `ChannelManager::handle_monitor_update_res` to panic on the mode mismatch. The root cause is that the mode check lived in `ChannelManager`, which sees the *post-override* status. By moving the check to `ChainMonitor` and running it against the *raw* `Persist` result (before the `update_res.is_err()` override), we validate only the user's persister behavior. ChainMonitor's internal override to `InProgress` for failed monitor updates no longer triggers a false mode violation. Also fix the `chanmon_consistency` fuzzer's `reload_node`, which hardcoded the persister to `Completed` before calling `watch_channel`, then switched to the node's actual mode afterward. With the mode check now in `ChainMonitor`, this caused a false violation. Set the persister to the correct mode before calling `watch_channel` so `ChainMonitor` sees a consistent persist mode from the start. Additionally, mirror pending monitor updates into `TestChainMonitor.latest_monitors` after `watch_channel` returns `InProgress`. The real `ChainMonitor` tracks the initial `update_id` as pending, but `TestChainMonitor` was unaware of it since `watch_channel` is called on the real `ChainMonitor` directly (bypassing `TestChainMonitor`). Without this, `complete_all_monitor_updates` could never drain and complete the update, leaving reloaded node channels permanently stuck. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

codecov · 2026-02-23T17:03:47Z

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.86%. Comparing base (2d2151a) to head (7e0a4dc).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/chainmonitor.rs	72.22%	5 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4435 +/- ##
==========================================
- Coverage 85.86% 85.86% -0.01% 
==========================================
Files 159 159 Lines 104302 104308 +6 Branches 104302 104308 +6 ==========================================
+ Hits 89558 89563 +5 + Misses 12246 12242 -4 - Partials 2498 2503 +5

Flag	Coverage Δ
tests	`85.86% <73.68%> (-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 · 2026-02-24T10:20:23Z

Closing in favor of alternative fix: #4436

joostjager · 2026-02-23T11:08:46Z

When ChannelMonitor::update_monitor fails (e.g. a counterparty commitment_signed arrives after funding was spent), ChainMonitor persists the full monitor successfully but overrides the return value to InProgress. If the user's Persist impl only returns Completed, this causes ChannelManager::handle_monitor_update_res to panic on the mode mismatch.

The root cause is that the mode check lived in ChannelManager, which sees the post-override status. By moving the check to ChainMonitor and running it against the rawPersist result (before the update_res.is_err() override), we validate only the user's persister behavior. ChainMonitor's internal override to InProgress for failed monitor updates no longer triggers a false mode violation.

ldk-reviews-bot · 2026-02-23T11:08:49Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

…inMonitor When `ChannelMonitor::update_monitor` fails (e.g. a counterparty `commitment_signed` arrives after funding was spent), `ChainMonitor` persists the full monitor successfully but overrides the return value to `InProgress`. If the user's `Persist` impl only returns `Completed`, this causes `ChannelManager::handle_monitor_update_res` to panic on the mode mismatch. The root cause is that the mode check lived in `ChannelManager`, which sees the *post-override* status. By moving the check to `ChainMonitor` and running it against the *raw* `Persist` result (before the `update_res.is_err()` override), we validate only the user's persister behavior. ChainMonitor's internal override to `InProgress` for failed monitor updates no longer triggers a false mode violation. Also fix the `chanmon_consistency` fuzzer's `reload_node`, which hardcoded the persister to `Completed` before calling `watch_channel`, then switched to the node's actual mode afterward. With the mode check now in `ChainMonitor`, this caused a false violation. Set the persister to the correct mode before calling `watch_channel` so `ChainMonitor` sees a consistent persist mode from the start. Additionally, mirror pending monitor updates into `TestChainMonitor.latest_monitors` after `watch_channel` returns `InProgress`. The real `ChainMonitor` tracks the initial `update_id` as pending, but `TestChainMonitor` was unaware of it since `watch_channel` is called on the real `ChainMonitor` directly (bypassing `TestChainMonitor`). Without this, `complete_all_monitor_updates` could never drain and complete the update, leaving reloaded node channels permanently stuck. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

codecov · 2026-02-23T17:03:47Z

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.86%. Comparing base (2d2151a) to head (7e0a4dc).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/chainmonitor.rs	72.22%	5 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4435 +/- ##
==========================================
- Coverage 85.86% 85.86% -0.01% 
==========================================
Files 159 159 Lines 104302 104308 +6 Branches 104302 104308 +6 ==========================================
+ Hits 89558 89563 +5 + Misses 12246 12242 -4 - Partials 2498 2503 +5

Flag	Coverage Δ
tests	`85.86% <73.68%> (-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 · 2026-02-24T10:20:23Z

Closing in favor of alternative fix: #4436

joostjager · 2026-02-23T11:08:46Z

When ChannelMonitor::update_monitor fails (e.g. a counterparty commitment_signed arrives after funding was spent), ChainMonitor persists the full monitor successfully but overrides the return value to InProgress. If the user's Persist impl only returns Completed, this causes ChannelManager::handle_monitor_update_res to panic on the mode mismatch.

The root cause is that the mode check lived in ChannelManager, which sees the post-override status. By moving the check to ChainMonitor and running it against the rawPersist result (before the update_res.is_err() override), we validate only the user's persister behavior. ChainMonitor's internal override to InProgress for failed monitor updates no longer triggers a false mode violation.

ldk-reviews-bot · 2026-02-23T11:08:49Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

…inMonitor When `ChannelMonitor::update_monitor` fails (e.g. a counterparty `commitment_signed` arrives after funding was spent), `ChainMonitor` persists the full monitor successfully but overrides the return value to `InProgress`. If the user's `Persist` impl only returns `Completed`, this causes `ChannelManager::handle_monitor_update_res` to panic on the mode mismatch. The root cause is that the mode check lived in `ChannelManager`, which sees the *post-override* status. By moving the check to `ChainMonitor` and running it against the *raw* `Persist` result (before the `update_res.is_err()` override), we validate only the user's persister behavior. ChainMonitor's internal override to `InProgress` for failed monitor updates no longer triggers a false mode violation. Also fix the `chanmon_consistency` fuzzer's `reload_node`, which hardcoded the persister to `Completed` before calling `watch_channel`, then switched to the node's actual mode afterward. With the mode check now in `ChainMonitor`, this caused a false violation. Set the persister to the correct mode before calling `watch_channel` so `ChainMonitor` sees a consistent persist mode from the start. Additionally, mirror pending monitor updates into `TestChainMonitor.latest_monitors` after `watch_channel` returns `InProgress`. The real `ChainMonitor` tracks the initial `update_id` as pending, but `TestChainMonitor` was unaware of it since `watch_channel` is called on the real `ChainMonitor` directly (bypassing `TestChainMonitor`). Without this, `complete_all_monitor_updates` could never drain and complete the update, leaving reloaded node channels permanently stuck. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

codecov · 2026-02-23T17:03:47Z

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.86%. Comparing base (2d2151a) to head (7e0a4dc).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/chainmonitor.rs	72.22%	5 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4435 +/- ##
==========================================
- Coverage 85.86% 85.86% -0.01% 
==========================================
Files 159 159 Lines 104302 104308 +6 Branches 104302 104308 +6 ==========================================
+ Hits 89558 89563 +5 + Misses 12246 12242 -4 - Partials 2498 2503 +5

Flag	Coverage Δ
tests	`85.86% <73.68%> (-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 · 2026-02-24T10:20:23Z

Closing in favor of alternative fix: #4436

joostjager · 2026-02-23T11:08:46Z

When ChannelMonitor::update_monitor fails (e.g. a counterparty commitment_signed arrives after funding was spent), ChainMonitor persists the full monitor successfully but overrides the return value to InProgress. If the user's Persist impl only returns Completed, this causes ChannelManager::handle_monitor_update_res to panic on the mode mismatch.

The root cause is that the mode check lived in ChannelManager, which sees the post-override status. By moving the check to ChainMonitor and running it against the rawPersist result (before the update_res.is_err() override), we validate only the user's persister behavior. ChainMonitor's internal override to InProgress for failed monitor updates no longer triggers a false mode violation.

ldk-reviews-bot · 2026-02-23T11:08:49Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

…inMonitor When `ChannelMonitor::update_monitor` fails (e.g. a counterparty `commitment_signed` arrives after funding was spent), `ChainMonitor` persists the full monitor successfully but overrides the return value to `InProgress`. If the user's `Persist` impl only returns `Completed`, this causes `ChannelManager::handle_monitor_update_res` to panic on the mode mismatch. The root cause is that the mode check lived in `ChannelManager`, which sees the *post-override* status. By moving the check to `ChainMonitor` and running it against the *raw* `Persist` result (before the `update_res.is_err()` override), we validate only the user's persister behavior. ChainMonitor's internal override to `InProgress` for failed monitor updates no longer triggers a false mode violation. Also fix the `chanmon_consistency` fuzzer's `reload_node`, which hardcoded the persister to `Completed` before calling `watch_channel`, then switched to the node's actual mode afterward. With the mode check now in `ChainMonitor`, this caused a false violation. Set the persister to the correct mode before calling `watch_channel` so `ChainMonitor` sees a consistent persist mode from the start. Additionally, mirror pending monitor updates into `TestChainMonitor.latest_monitors` after `watch_channel` returns `InProgress`. The real `ChainMonitor` tracks the initial `update_id` as pending, but `TestChainMonitor` was unaware of it since `watch_channel` is called on the real `ChainMonitor` directly (bypassing `TestChainMonitor`). Without this, `complete_all_monitor_updates` could never drain and complete the update, leaving reloaded node channels permanently stuck. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

codecov · 2026-02-23T17:03:47Z

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.86%. Comparing base (2d2151a) to head (7e0a4dc).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/chainmonitor.rs	72.22%	5 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4435 +/- ##
==========================================
- Coverage 85.86% 85.86% -0.01% 
==========================================
Files 159 159 Lines 104302 104308 +6 Branches 104302 104308 +6 ==========================================
+ Hits 89558 89563 +5 + Misses 12246 12242 -4 - Partials 2498 2503 +5

Flag	Coverage Δ
tests	`85.86% <73.68%> (-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 · 2026-02-24T10:20:23Z

Closing in favor of alternative fix: #4436

joostjager · 2026-02-23T11:08:46Z

When ChannelMonitor::update_monitor fails (e.g. a counterparty commitment_signed arrives after funding was spent), ChainMonitor persists the full monitor successfully but overrides the return value to InProgress. If the user's Persist impl only returns Completed, this causes ChannelManager::handle_monitor_update_res to panic on the mode mismatch.

The root cause is that the mode check lived in ChannelManager, which sees the post-override status. By moving the check to ChainMonitor and running it against the rawPersist result (before the update_res.is_err() override), we validate only the user's persister behavior. ChainMonitor's internal override to InProgress for failed monitor updates no longer triggers a false mode violation.

ldk-reviews-bot · 2026-02-23T11:08:49Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

…inMonitor When `ChannelMonitor::update_monitor` fails (e.g. a counterparty `commitment_signed` arrives after funding was spent), `ChainMonitor` persists the full monitor successfully but overrides the return value to `InProgress`. If the user's `Persist` impl only returns `Completed`, this causes `ChannelManager::handle_monitor_update_res` to panic on the mode mismatch. The root cause is that the mode check lived in `ChannelManager`, which sees the *post-override* status. By moving the check to `ChainMonitor` and running it against the *raw* `Persist` result (before the `update_res.is_err()` override), we validate only the user's persister behavior. ChainMonitor's internal override to `InProgress` for failed monitor updates no longer triggers a false mode violation. Also fix the `chanmon_consistency` fuzzer's `reload_node`, which hardcoded the persister to `Completed` before calling `watch_channel`, then switched to the node's actual mode afterward. With the mode check now in `ChainMonitor`, this caused a false violation. Set the persister to the correct mode before calling `watch_channel` so `ChainMonitor` sees a consistent persist mode from the start. Additionally, mirror pending monitor updates into `TestChainMonitor.latest_monitors` after `watch_channel` returns `InProgress`. The real `ChainMonitor` tracks the initial `update_id` as pending, but `TestChainMonitor` was unaware of it since `watch_channel` is called on the real `ChainMonitor` directly (bypassing `TestChainMonitor`). Without this, `complete_all_monitor_updates` could never drain and complete the update, leaving reloaded node channels permanently stuck. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

codecov · 2026-02-23T17:03:47Z

Codecov Report

❌ Patch coverage is 73.68421% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.86%. Comparing base (2d2151a) to head (7e0a4dc).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/chainmonitor.rs	72.22%	5 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4435 +/- ##
==========================================
- Coverage 85.86% 85.86% -0.01% 
==========================================
Files 159 159 Lines 104302 104308 +6 Branches 104302 104308 +6 ==========================================
+ Hits 89558 89563 +5 + Misses 12246 12242 -4 - Partials 2498 2503 +5

Flag	Coverage Δ
tests	`85.86% <73.68%> (-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 · 2026-02-24T10:20:23Z

Closing in favor of alternative fix: #4436

joostjager force-pushed the fix-chainmonitor-mode-violation branch from 79be78c to abe9d13Compare February 23, 2026 11:39

joostjager force-pushed the fix-chainmonitor-mode-violation branch from abe9d13 to 7e0a4dcCompare February 23, 2026 14:00

joostjager closed this Feb 24, 2026

joostjager mentioned this pull request Feb 24, 2026
Replace dual-sync-async persistence panic with Watch contract #4436
Merged

joostjager force-pushed the fix-chainmonitor-mode-violation branch from 79be78c to abe9d13Compare February 23, 2026 11:39

joostjager force-pushed the fix-chainmonitor-mode-violation branch from abe9d13 to 7e0a4dcCompare February 23, 2026 14:00

joostjager closed this Feb 24, 2026

joostjager mentioned this pull request Feb 24, 2026
Replace dual-sync-async persistence panic with Watch contract #4436
Merged

joostjager force-pushed the fix-chainmonitor-mode-violation branch from 79be78c to abe9d13Compare February 23, 2026 11:39

joostjager force-pushed the fix-chainmonitor-mode-violation branch from abe9d13 to 7e0a4dcCompare February 23, 2026 14:00

joostjager closed this Feb 24, 2026

joostjager mentioned this pull request Feb 24, 2026
Replace dual-sync-async persistence panic with Watch contract #4436
Merged

joostjager force-pushed the fix-chainmonitor-mode-violation branch from 79be78c to abe9d13Compare February 23, 2026 11:39

joostjager force-pushed the fix-chainmonitor-mode-violation branch from abe9d13 to 7e0a4dcCompare February 23, 2026 14:00

joostjager closed this Feb 24, 2026

joostjager mentioned this pull request Feb 24, 2026
Replace dual-sync-async persistence panic with Watch contract #4436
Merged

joostjager force-pushed the fix-chainmonitor-mode-violation branch from 79be78c to abe9d13Compare February 23, 2026 11:39

joostjager force-pushed the fix-chainmonitor-mode-violation branch from abe9d13 to 7e0a4dcCompare February 23, 2026 14:00

joostjager closed this Feb 24, 2026

joostjager mentioned this pull request Feb 24, 2026
Replace dual-sync-async persistence panic with Watch contract #4436
Merged

joostjager force-pushed the fix-chainmonitor-mode-violation branch from 79be78c to abe9d13Compare February 23, 2026 11:39

joostjager force-pushed the fix-chainmonitor-mode-violation branch from abe9d13 to 7e0a4dcCompare February 23, 2026 14:00

joostjager closed this Feb 24, 2026

joostjager mentioned this pull request Feb 24, 2026
Replace dual-sync-async persistence panic with Watch contract #4436
Merged

joostjager force-pushed the fix-chainmonitor-mode-violation branch from 79be78c to abe9d13Compare February 23, 2026 11:39

joostjager force-pushed the fix-chainmonitor-mode-violation branch from abe9d13 to 7e0a4dcCompare February 23, 2026 14:00

joostjager closed this Feb 24, 2026

joostjager mentioned this pull request Feb 24, 2026
Replace dual-sync-async persistence panic with Watch contract #4436
Merged

joostjager force-pushed the fix-chainmonitor-mode-violation branch from 79be78c to abe9d13Compare February 23, 2026 11:39

joostjager force-pushed the fix-chainmonitor-mode-violation branch from abe9d13 to 7e0a4dcCompare February 23, 2026 14:00

joostjager closed this Feb 24, 2026

joostjager mentioned this pull request Feb 24, 2026
Replace dual-sync-async persistence panic with Watch contract #4436
Merged

Uh oh!

Conversation

joostjager commented Feb 23, 2026

Uh oh!

ldk-reviews-bot commented Feb 23, 2026

Uh oh!

codecovBot commented Feb 23, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

joostjager commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

joostjager commented Feb 23, 2026

Uh oh!

ldk-reviews-bot commented Feb 23, 2026

Uh oh!

codecovBot commented Feb 23, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

joostjager commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

joostjager commented Feb 23, 2026

Uh oh!

ldk-reviews-bot commented Feb 23, 2026

Uh oh!

codecovBot commented Feb 23, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

joostjager commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

joostjager commented Feb 23, 2026

Uh oh!

ldk-reviews-bot commented Feb 23, 2026

Uh oh!

codecovBot commented Feb 23, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

joostjager commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codecovBot commented Feb 23, 2026•
edited
Loading

codecovBot commented Feb 23, 2026•
edited
Loading

codecovBot commented Feb 23, 2026•
edited
Loading

codecovBot commented Feb 23, 2026•
edited
Loading

codecovBot commented Feb 23, 2026•
edited
Loading

codecovBot commented Feb 23, 2026•
edited
Loading