Drop completed blocked `ChannelMonitorUpdate`s on startup
authorMatt Corallo <git@bluematt.me>
Thu, 25 Apr 2024 14:30:05 +0000 (14:30 +0000)
committerMatt Corallo <git@bluematt.me>
Thu, 25 Apr 2024 18:39:56 +0000 (18:39 +0000)
commit6b45237f46590eda6412402fb40c1fb0831ed828
tree22cba8aba8eb50bf2135a6ce446dc21b95ed4dec
parent6d26a0c265a62450bb990f7354e92ff6332e451d
Drop completed blocked `ChannelMonitorUpdate`s on startup

If a user receives a payment preimage for an outbound payment, the
`PaymentSent` event will block any eventual RAA
`ChannelMonitorUpdate` from the same channel, assuming it comes in
before the event can be processed. If this blocking kicks in, but
the flow eventually completes with the RAA `ChannelMonitorUpdate`
being persisted, but the `ChannelManager` is only persisted prior
to the event being handled, on startup we'll have a fully
up-to-date `ChannelMonitor` but a pending, blocked
`ChannelMonitorUpdate`. When the `PaymentSent` event is replayed
we'll end up trying to apply a redundant `ChannelMonitorUpdate`
which will panic.

See the test added in this commit for an implementation of this
situation.

In this commit we fix this issue by simply dropping blocked
`ChannelMonitorUpdate`s the same as we do pending ones.
lightning/src/ln/channel.rs
lightning/src/ln/channelmanager.rs
lightning/src/ln/monitor_tests.rs