-
Notifications
You must be signed in to change notification settings - Fork 7
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
Lightning address receive inconsistent and fails sometimes. No way to recover or view queued ln address receipts #122
Comments
Will come to that later to inspect, for now just sent 21sats from speed wallet to your address. Ping if you've received
Wallet tries to claim on fresh start and then roughly once per min while in active use / coming to foreground. |
I received the 21sats and understand the other points. I did test before and after the failed transaction and they had passed to the wallet fine. Although they would only update on restart (close the app). It never updated after a minute or bringing the wallet to the foreground. That update feature seems to not be working. I included all the lightning address transactions in the csv file I attached. I only opened the ticket so you can troubleshoot the failed 100 sats transaction on your side since it could be a bug. However if you feel this is an issue related to losing the state during an update of the service I'm fine with closing the issue. |
I'll keep this open till I check the transaction above. The periodic claim checks should work e.g. in case you go to any other screen and move back to main wallet screen after more then 60s. Or in case you keep app in background and get it back to active after 60+s. Thank you |
OK thanks. Testing the claims check now and it's receiving normally. Not sure why, the only difference is I turned on notifications but it's been working even after turning it back off. So for now I'll ignore that. Cheers |
I've checked the above 100 sats test payment, lightning payment succeeded and LNURL server tracks it as claimed by the wallet. I set it's status as unclaimed. On next start wallet should get it again and receive successfully had it not been before. Otherwise it should create error transaction. |
No Joy, but a new lightning address transaction I sent just now did go through without hitch. No error message seen but I also don't know how to export the log on this. I'm also thinking perhaps it came through but didn't show up on the transaction history. There doesn't seem a way to export it but I checked the running balance and it doesn't match the balance. However I did draw down the wallet balance to 0 before this last round of testing and that does match up. I can keep trying to reproduce a failed lightning address payment then send you that one as well. But so far it seems to be running fine since last update. Dev options show it as commit: d5422af db version:18 JS Bundle: 0.1.10-beta.4 |
Hello I have a similar (or same) issue here. I wished I saw this tread before as I am waiting for 20000 Sats to reach my minibits wallet from my lightning node. |
I've been mostly testing the wallet and interoperability. After the last update ecash tokens are marked received properly so I moved on to testing lightning address to make sure that was still working. It seems to be broken. I get some transactions as expected while others fail. I can't troubleshoot more than that since it's on the minibits mint side so I'm including the transactions I tested with. The one for 100 sats total never transferred to the minibits wallet. I don't need the sats I'm just hoping to get this working well enough for normies. I think having offline lightning capability is very useful for my orange pilling activities.
BreezPayments_7.12.24-8.12.24.csv
Lightning Address payment detail below. Sent successfully but failed to appear in minibits wallet: [email protected]
12/7/2024 11:32 PM minibits.cash Minibits 0330974249e7f1d9f515e04af3bc664b2e924641de53bb43fb9efe3fa6edf0e2ae 100 53d7031a35a02de395f90236b076a885d3aa1f5c504e666c211f72a4fe0887a1 5a3674263bf17ae1b66a16f95d160ec70d06b2f703b094e4eb99957909926aa6 0
The text was updated successfully, but these errors were encountered: