Add singleton actor AsyncPaymentTriggerer to monitor when the receiver of an async payment reconnects - #2491
Conversation
4b286a2 to
a1bd1b4
Compare
Codecov Report
@@ Coverage Diff @@
## master #2491 +/- ##
==========================================
+ Coverage 85.11% 85.24% +0.12%
==========================================
Files 203 204 +1
Lines 16081 16107 +26
Branches 706 689 -17
==========================================
+ Hits 13688 13731 +43
+ Misses 2393 2376 -17
|
AsyncPaymentTrigger to monitor when the receiver of an async payment reconnects AsyncPaymentTriggerer to monitor when the receiver of an async payment reconnects
t-bast
left a comment
There was a problem hiding this comment.
Looks good to me, the design is clean and test coverage looks good.
I did some refactoring and renaming in ac5118b, let me know what you think.
I'll update #2464 to allow disabling the timeout, I think it's useful to have. I'll do it slightly differently than what you did, I think using an Option is more explicit than an infinite duration.
839f406 to
bfdb294
Compare
026ea4e to
c72c6be
Compare
|
Do we need to add Otoh, we will need a way for a node that creates an async payment to cancel a pending payment queued by the trampoline node they designated to hold it. This will likely be accomplished with a custom onion message, but could also be a custom Lightning Message. |
I think you should indeed rollback 0c7b049 I think there is a confusion between the sender node and the relaying node here. Cancelling an async payment is done by the sender node telling the relaying node to abort the payment via a custom lightning message or an onion message. The API is for the relaying node operator, but it's not their decision to cancel async payments. I don't think you should add anything else to this PR, it's just making it harder to review. Follow-up work (e.g. adding the custom |
This reverts commit 0c7b049.
The new
AsyncPaymentTriggerersingleton actor spawns only a singlePeerReadyNotifieractor for each peer that is watched. This prevents multiple actors from redundantly polling for when the same peer reconnects.Each
Watcherfor a given peer triggers a specific async payment (managed by aNodeRelayactor) and has a unique timeout (in block height). TheNodeRelayactor will receive anAsyncPaymentTriggeredwhen the target peer reconnects, orAsyncPaymentTimeoutif the timeout block height is reached.This PR requires a change to allow
PeerReadyNotifierto have an infinite timeout so thatAsyncPaymentTriggerercan instead manage multiple timeouts for a given peer.The
AsyncPaymentTriggerersingleton must be created before theRelayeractor is created, but requires a reference to the singletonSwitchboardactor to spawnPeerReadyNotifieractors. Because the swtichboard is indirectly instantiated with theRelayerreference (viaPeerFactoryandChannelFactory), theAsyncPaymentTriggereractor must be further initialized by sending aStartmessage with theSwitchboardactor reference before being used.In the future the
AsyncPaymentTriggereractor can be extended to watch for onion messages from async payment receivers, instead of only watching for local peer re-connections. In the onion message case, thepaymentHashwill be used to identify whichWatcherto trigger.