Commit 20ebcd3
committed
Ack monitor events when failing-to-fail-backwards
Currently, the resolution of HTLCs (and decisions on when HTLCs can be
forwarded) is the responsibility of Channel objects (a part of ChannelManager)
until the channel is closed, and then the ChannelMonitor thereafter. This leads
to some complexity around race conditions for HTLCs right around channel
closure. Additionally, there is lots of complexity reconstructing the state of
all HTLCs in the ChannelManager deserialization/loading logic.
Instead, we want to do all resolution in ChannelMonitors (in response to
ChannelMonitorUpdates) and pass them back to ChannelManager in the form of
MonitorEvents (similar to how HTLCs are resolved after channels are closed). In
order to have reliable resolution, we'll need to keep MonitorEvents around in
the ChannelMonitor until the ChannelManager has finished processing them. This
will simplify things - on restart instead of examining the set of HTLCs in
monitors we can simply replay all the pending MonitorEvents.
Here we build on recent commits by ACK'ing monitor events for forward failures
if we go to fail on the inbound edge and get an error when queueing the
backwards failure. If we get an error in this case it means the failure is
duplicate or the channel is closed, and in either case it's fine to mark the
event as resolved.1 parent 4282345 commit 20ebcd3
1 file changed
+7
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
8196 | 8196 | | |
8197 | 8197 | | |
8198 | 8198 | | |
| 8199 | + | |
8199 | 8200 | | |
8200 | 8201 | | |
8201 | 8202 | | |
| |||
8228 | 8229 | | |
8229 | 8230 | | |
8230 | 8231 | | |
8231 | | - | |
| 8232 | + | |
8232 | 8233 | | |
8233 | 8234 | | |
8234 | 8235 | | |
| |||
8241 | 8242 | | |
8242 | 8243 | | |
8243 | 8244 | | |
8244 | | - | |
| 8245 | + | |
| 8246 | + | |
8245 | 8247 | | |
| 8248 | + | |
| 8249 | + | |
| 8250 | + | |
8246 | 8251 | | |
8247 | 8252 | | |
8248 | 8253 | | |
| |||
0 commit comments