]> git.bitcoin.ninja Git - rust-lightning/commit
Unblock channels awaiting monitor update based on `ChanMan` queue 2024-04-async-monitor-fuzz
authorMatt Corallo <git@bluematt.me>
Tue, 11 Jun 2024 01:39:48 +0000 (01:39 +0000)
committerMatt Corallo <git@bluematt.me>
Wed, 12 Jun 2024 15:32:33 +0000 (15:32 +0000)
commit920d96edb6595289902f287419de2d002e2dc2ee
treed6b180e1d118644d20f9884fb57bdaa32ba45701
parentd5019fc4d8afc8cd714041e16f32a74ce8f486cd
Unblock channels awaiting monitor update based on `ChanMan` queue

When we have `ChannelMonitorUpdate`s which are completing both
synchronously and asynchronously, we need to consider a channel as
unblocked based on the `ChannelManager` monitor update queue,
rather than by checking the `update_id`s.

Consider the case where a channel is updated, leading to a
`ChannelMonitorUpdate` which completes asynchronously. The update
completes, but prior to the `ChannelManager` receiving the
`MonitorEvent::Completed` it generates a further
`ChannelMonitorUpdate`. This second update completes synchronously.
As a result, when the `MonitorEvent` is processed, the event's
`monitor_update_id` is the first update, but there are no updates
queued and the channel should be free to return to be unblocked.

Here we fix this by looking only at the `ChannelManager` update
queue, rather than the update_id of the `MonitorEvent`.

While we don't anticipate many users having both synchronous and
asynchronous persists in the same application, there isn't much
cost to supporting it, which we do here.

Found by the chanmon_consistency target.
lightning/src/ln/chanmon_update_fail_tests.rs
lightning/src/ln/channelmanager.rs