-
Notifications
You must be signed in to change notification settings - Fork 45
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
Return invoice on successful lnurl-withdraw #436
Conversation
085f429
to
145fa91
Compare
@roeierez it's ready for review. I will add the RN bindings as last step, once we agree on the general structure. |
It could be the first use of the RN codegen 😎 |
The PR simply adds the invoice in the withdraw However, if the goal is to be able to link a payment with a LNURL-withdraw request, an alternative way to do this is to extend with an That may be preferable to the approach in this PR, because with the PR, our LNURL handling becomes inconsistent:
What do you think? Is the PR approach ok? Or better switch to the above? Or do both? |
If possible, as a user, I would like to have both :) that way, I can avoid always searching for the correct payment after making an LNURL withdrawal. Otherwise, the withdrawal flow is:
If we have what the current version of this PR proposes, the middle step can be discarded. |
08aaabf
to
335e61f
Compare
@dangeross I took your RN generator for a test-drive and ran it on this PR. Can you please doublecheck if all looks good? fe8884d |
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.
Looks good in general. There seems to be lots of linting changes with the kotlin files though. Can you give me your ktlint and kotlin versions?
ktlint --version
kotlin -version
1.0.0
Kotlin version 1.9.10-release-459 (JRE 20.0.2) |
Ok, seems to be a version difference. I've upgraded to 1.0.0 |
@ok300 the PR looks good to me. As for your comment above do you want to add the step of associated the withdraw endpoint with the payment in the storage or not? Another option is in a 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.
LGTM! We need a corresponding c-breez PR as I believe this breaks it.
Then I'll add both in this PR. |
e779168
to
fd8c3d7
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.
Looks good! Dropped a NIT comment.
libs/sdk-core/src/models.rs
Outdated
@@ -1114,6 +1117,18 @@ pub enum LnUrlCallbackStatus { | |||
}, | |||
} | |||
|
|||
/// [LnUrlCallbackStatus] specific to LNURL-withdraw, where the success case contains the invoice. | |||
#[derive(Serialize)] | |||
pub enum LnUrlWithdrawCallbackStatus { |
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.
Perhaps if we are introducing new types here we can use better naming?
LnUrlWithdrawCallbackStatus
=> LnUrlWithdrawResult
LnUrlWithdrawOkData
=> LnurlWithdrawSuccess
LnUrlErrorData
=> LnurlError
35d0171
to
cdd81b8
Compare
Persist failed payments breez/breez-sdk-greenlight#463 Return invoice on successful lnurl-withdraw breez/breez-sdk-greenlight#436
@erdemyerebasmaz how about It's used not only in LNURL-auth, but also as intermediary step in LNURL-withdraw. |
@ok300 I see, isn't it supposed to be
The naming was fine and consistent with other parts of the app before these changes imo. |
Well, there are 2 naming conventions which don't overlap:
|
Thanks for the clarification, second item was what made it confusing for me. If that's the case, I see no issue with keeping |
Then @roeierez this PR is ready for final review. I also linked the c-breez PR by @erdemyerebasmaz in the description above. |
8e1096e
to
d8ccf23
Compare
Persist failed payments breez/breez-sdk-greenlight#463 Return invoice on successful lnurl-withdraw breez/breez-sdk-greenlight#436
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.
Looks good!
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
Persist failed payments breez/breez-sdk-greenlight#463 Return invoice on successful lnurl-withdraw breez/breez-sdk-greenlight#436
Persist failed payments breez/breez-sdk-greenlight#463 Return invoice on successful lnurl-withdraw breez/breez-sdk-greenlight#436
Include the
LNInvoice
as inner data in theOk
result ofBreezServices::lnurl_withdraw
.Subtasks:
list_payments
Fixes #427