-
Notifications
You must be signed in to change notification settings - Fork 29
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
Slow payments using Breez SDK #502
Comments
There's 5 minutes log in the slow one... What's the node pubkey? |
@kingonly Okay, attaching a new log file. This time I took note of the details you requested. Node Pubkey/Id
Payment Timestamp
Payment Destination
|
This is a payment to Phoenix. Are you testing it on the same device? Can you please send to another device? Sending between two non custodial wallets on the same device can explain the latency. |
@kingonly I used two separate devices, a physical Samsung phone running Phoenix on android and the other is an iOS simulator running our app. They were on the same network. |
@cdecker could you help me debug this payment? I can pay Phoenix quickly in my environment fwiw |
FWIW here is another log where we pay an invoice to WoS from our app, two separate devices as before. Same pubkey/node id. Payment timestamp |
For future reference the sessions are:
Looking at the slow payments only here 7231591378063360Timeline
The first successful payment
The second payment:
So as you can see we get unlucky and try a channel
The remaining payments in the logs are aggregated as this:
(This is the output of a log slicer that I'm building, since analyzing As you can see we're losing a lot of time talking to If desired I can analyse the other logs too, but I think this |
@yaslama please take a look at our channels with this node. Perhaps we should close our channels, although it seems like large routing node. Meanwhile, we've opened direct channels to Acinq to mitigate this issue. Please report if this problem persists. |
We have new channels to Acinq and it should be sufficient to mitigate the issue. But i also closed the channel to 02a98e8c |
We are still experiencing times well above 15s, anywhere from 30s - 1m30s both to non-custodial and custodial recipients. What else can be done to get this resolved? Happy to assist wherever possible. |
Provide the details of a specific payment and we'll take a look |
Hey guys Summary of the problem:
I'm concerned that this discussion has gotten to a point where the resolution was to fix a route with Phoenix, but I can't see how this solves the "general slowness" that we're facing. |
The problem is that we're not aware of a general issue. I don't see any other way than debugging specific payments. Please share more info in the issue re specific payments so we could follow up with the GL team. We're also working on a trampoline payments implementation that might mitigate this issue but we're still a few weeks away from delivering it. |
Apologies for not providing the requested ETA for general enhancements of payments. We were heads down implementing it, and we're getting close with CLN#7494, but sadly we missed the release window for v24.08. As soon as we've finalized the PR we will start back porting it onto v24.02 which corresponds to the latest Breez SDK, and from there on we can fine tune in the servers quickly. So a couple of weeks at most for general improvements. In the meantime the trampoline progress is looking promising, and that'll alleviate the issue maybe even a bit quicker. |
We're using Breez SDK and while testing paying lightning invoices we experience anywhere from 30s to multiple minutes of delay before a payment completes fully where the latter is an unacceptable UX to us. I've tried to get to the bottom of this with the Breez team but they've told me to open an issue here, so here it is. Attached you'll find two logs, one for a relatively fast payment and one for what we experience to be a slow payment.
breez-payment-fast.log
breez-payment-slow.log
Any help/guidance as to what might be causing this and how to resolve this would be greatly appreciated.
The text was updated successfully, but these errors were encountered: