-
Notifications
You must be signed in to change notification settings - Fork 43
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
Yield call to send_payment after a timeout and return a pending payment #943
base: main
Are you sure you want to change the base?
Conversation
772e7f7
to
1128f90
Compare
4a730da
to
fd46a2f
Compare
fd46a2f
to
cd99a34
Compare
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.
A small simplification suggested.
@@ -749,6 +750,7 @@ dictionary SendPaymentRequest { | |||
string bolt11; | |||
u64? amount_msat = null; | |||
string? label = null; | |||
u64? pending_timeout_sec = null; |
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.
Do we need this? Why not using the payment_timeout from the config?
let pending_timeout_sec = req.pending_timeout_sec.unwrap_or(u64::MAX); | ||
let (tx, rx) = std::sync::mpsc::channel(); | ||
let cloned = self.clone(); | ||
tokio::spawn(async move { |
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.
Instead of using an async task and a channel perhaps we can simplify by using tokio::time::timeout ?
for example:
let result = tokio::time::timeout(Duration::from_seconds(pending_timeout), node_api.send_payment... )
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.
I've set this PR to draft while we work on other things, @ok300 has a proposal to improve it
But regarding the tokio timeout, isn't the future cancelled if the timeout occurs? In our case the future has to complete with or without timeout
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.
I see, good point as we don't want to show error while still pending.
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.
Also we want the sync to complete in the background if pending is already returned and the Payment(Succeed/Failed) to be emitted
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.
I added #958 to fix some issues around that and improve handling.
It's using a combination of both your ideas:
- the channel (
tx
,rx
) tokio::time::timeout(Duration::from_secs(pending_timeout_sec), rx).await
The failing tests would be fixed by #958 |
This adds the following to the SDK:
send_payment()
request in a thread with a timeout to prevent the method call hanging too long. If it times out, the pending Payment is returned and the client can then use the PaymentSucceed / PaymentFailed events to handle the completion of the payment.lnurl_pay()
request (which usessend_payment()
) without a timeout.