-
Notifications
You must be signed in to change notification settings - Fork 901
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
delpay: introduced a new rpc method to delete a payment by hash #3899
delpay: introduced a new rpc method to delete a payment by hash #3899
Conversation
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 that the
LIGHTNINGD
error is marked with aFIXME
because each command should use the correct error code. I'm not able to find the payment error codes inside the code. maybe we could define the payment error code?
PAY_NO_SUCH_PAYMENT
seems appropriate if the specified hash does not match any payments. Define a new PAY_STATUS_UNEXPECTED
for the case where it does not match the expected status.
In addition, it seems to me better to just delete all |
Hi @ZmnSCPxj, thanks to review this PR. I will make the changes inside the docs and inside the JSON RPC errors, sorry about that. In addition, about your suggestion.
For my code comprehension, to make this work, so, to delete the complete payment and not each payment by I'm losing something? Maybe I can use the |
But you want to check the state of the entire payment first. The logic for a purported "payment state":
It is safe to delete a payment if the entire payment is failed or succeeded, and we should probably disallow deleting pending payments (which might still be operated by Note that if you do not pass control to a function with a callback, then the entire processing is done inside a database transaction, so you are assured that between the check and the deletion, the database state is consistent. But if you pass control to a function with a callback, the database transaction will end at that point, and by the time the callback is called, you are in a new transaction. So do not call into any callback-using functions between checking the state of the payment and deleting the whole payment. |
Thanks for the suggestion @ZmnSCPxj.
I make the sanity test of input before to call the database function, but I can improve the check maybe I can make the following test:
of course, there are all checks on the input but, they are not relevant into this description.
Yep, I agree, with my actual logic inside the |
|
bfb4282
to
3a5f0be
Compare
Rebased 01a82d3 and updated vincenzopalazzo@8fef912 |
3a5f0be
to
8fef912
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.
Mostly style nits.
8fef912
to
627a374
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.
@ZmnSCPxj In addition, I need a feedback on this change 😄 sorry about that
627a374
to
86a0fa5
Compare
Mostly grammatical/spelling fixes. In general, for documentation, less words is better :) |
159a349
to
8d3cf55
Compare
Rebase and update with suggestions. Thanks @niftynei about the fixes and sorry for the spelling errors. I'm still searching somethings where I'm good to do but I'm sure that I'm very bad to write sentences 😄 |
8d3cf55
to
68a2b06
Compare
doc/lightning-delpay.7.md
Outdated
RETURN VALUE | ||
------------ | ||
|
||
On success, the command will return a payment object, such as the **listsendpays**. If the payment is aa MPP (multi part payment) the command return a list of |
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.
On success, the command will return a payment object, such as the **listsendpays**. If the payment is aa MPP (multi part payment) the command return a list of | |
If successful the command returns a payment object, in the same format as **listsendpays**. | |
If the payment is a multi-part payment (MPP) the command return a list of |
lightningd/pay.c
Outdated
if (status == PAYMENT_PENDING) | ||
return command_fail(cmd, JSONRPC2_INVALID_PARAMS, "Invalid status: %s", | ||
payment_status_to_string(status)); |
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.
Probably it's better to check if we have one of the valid statuses instead of not having the third. If we ever add a new status this is would not cover that fourth state. If you use a switch
statement then the compiler will make sure we cover all cases exhaustively.
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 for this suggestion, I made the change from if to switch!
tests/test_pay.py
Outdated
# payment unpaid with wrong status (pending status is a illegal input) | ||
with pytest.raises(RpcError): | ||
l2.rpc.delpay(payment_hash, '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.
Payment was no attempted at all, so it'd fail for that reason already.
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 this is testing our sanity check order, and not the underlying pending
vs. non-pending
cases.
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.
This comment brings me to reflect on the sens of this test!
I moved the pay command to the top of this sanity check, so, with this new situation the unit test has more sense to me because it does the sanity check and the command behavior checks
tests/test_pay.py
Outdated
|
||
l1, l2, l3 = node_factory.line_graph( | ||
3, fundamount=10**8, wait_for_announce=True, | ||
opts={'wumbo': None} |
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.
Wumbo is not needed here: MPP_TARGET_SIZE
is denominated in msats, whereas the fundamount
is denominated in sats. So this creates a channel that is 4 orders of magnitude larger than the amount being transferred:
- Channel capacity:
10**8 * 1000 = 10**11
- Payment amount:
5 * 10**7
Doesn't hurt though 😉
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.
Doesn't hurt though
Yes, it is, but it is also my logic error, I discovered only now that fundamount
is denominated in sats. I think that 10**5
is enough
68a2b06
to
3314a05
Compare
Rebase and update with review 3314a05
|
4274fe4
to
8879acc
Compare
5ad8db7
to
ef0bd3a
Compare
b4fe30f
to
da4ff41
Compare
Rebased on top of |
d792432
to
a184f3b
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.
ACK 56a5dc9
Changelog-Added: JSON-RPC: delpay a new method to delete the payment completed or failed. Signed-off-by: Vincenzo Palazzo <[email protected]>
Signed-off-by: Vincenzo Palazzo <[email protected]>
56a5dc9
to
db53235
Compare
Ack db53235 |
Hi all.
This Draft implement a new RPC command to delete the payment with the status
complete
failed
marked like good first issue #1995However, this PR depends from the PR where I proposed to update the result of listpays command with
payment_hash
inside the result #3888. In addition, with the @cdecker suggestion to add thepayment_hash
in all cases of types of payments, the commanddelpay
can use only thepayment_hash
to identify the payment to remove and notbolt11
.This PR is a draft yet because I have some point to clarify with the team, for instance, the type of error that the command should be returned in cases of error. In other words, I see that the
LIGHTNINGD
error is marked with aFIXME
because each command should use the correct error code. I'm not able to find the payment error codes inside the code. maybe we could define the payment error code?Changelog-Added: JSON-RPC: delpay a new method to delete the payment completed or failed.