-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start publishing PaymentForwarded events. #404
Conversation
404 Secured! |
Pushed minor fix to fix CI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This is somewhat preexisting, but will be more important if we introduce this event: going forward we need to consider steps to mitigate the potential DoS issue that might arise if users don't handle events fast enough and our event queue and forwarding/payment stores grow unboundedly.
Maybe we should extend the docs on Node
in general and Node::next_event
to stress more explicitly that users really need to handle events as fast as possible, especially if they would ever open announced channels? Also, we might need to consider starting to bound the event queue as dropping events is preferable to risk running OOM?
So I think we should take some (initial) mitigation steps as part of this PR or as a follow-up.
I don't think dropping events is a good idea, as users might miss that information. (discussed it offline in dev-sync, we need a way for ldk to somehow stop publishing events if event queue is beyond some large threshold.)
I understand, will do it as separate PR. |
Created #405 as separate PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a follow-up to @tnull's comment, I have just a small question about event handling for older-versioned events in the event queue of upgraded nodes.
Addressed all comments, kept prev_channel_id & next_channel_id as non-optional since there was never an ldk-node release with LDK < 0.0.0115. (and those were introduced in 0.0.107) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically LGTM (mod addressing/clarifying open comments).
Could you add some basic test coverage for this, e.g., by adding some
expect_event!(nodes[X], PaymentForwarded);
checks for the intermediate node in the multi_hop_sending
test?
@G8XSU Let me know when you addressed the final round of comments/added some test coverage. |
Addressed comments, Added tests and asserting over single payment path, waiting for CI and msrv check. Do i need to send it over specific path and then assert? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, mod one comment and one nit.
Feel free to address them while squashing in the fixups to get this in a mergeable state.
Required for ldk-server implementation or rather any forwarding node. Since a mobile node shouldn't be forwarding payments, these shouldn't get generated for mobile nodes.
1d0aec2
to
d8d9002
Compare
Squashed with current fixups, |
Required for ldk-server implementation or rather any forwarding node. Since a mobile node shouldn't be forwarding payments, these shouldn't get generated for mobile nodes.