classPostRestartHtlcCleaner extends Actor with ActorLogging
If we have stopped eclair while it was handling HTLCs, it is possible that we are in a state were incoming HTLCs were
committed by both sides, but we didn't have time to send and/or sign corresponding HTLCs to the downstream node.
It's also possible that we partially forwarded a payment (if MPP was used downstream): we have lost the intermediate
state necessary to retry that payment, so we need to wait for the partial HTLC set sent downstream to either fail or
fulfill (and forward the result upstream).
If we were sending a payment (no downstream HTLCs) when we stopped eclair, we might have sent only a portion of the
payment (because of multi-part): we have lost the intermediate state necessary to retry that payment, so we need to
wait for the partial HTLC set sent downstream to either fail or fulfill the payment in our DB.
If we have stopped eclair while it was handling HTLCs, it is possible that we are in a state were incoming HTLCs were committed by both sides, but we didn't have time to send and/or sign corresponding HTLCs to the downstream node. It's also possible that we partially forwarded a payment (if MPP was used downstream): we have lost the intermediate state necessary to retry that payment, so we need to wait for the partial HTLC set sent downstream to either fail or fulfill (and forward the result upstream).
If we were sending a payment (no downstream HTLCs) when we stopped eclair, we might have sent only a portion of the payment (because of multi-part): we have lost the intermediate state necessary to retry that payment, so we need to wait for the partial HTLC set sent downstream to either fail or fulfill the payment in our DB.