Skip to content

Conversation

@f321x
Copy link
Member

@f321x f321x commented Oct 20, 2025

Allows storing two different payment info of the same payment hash by
including the direction into the db key.
We create and store PaymentInfo for sending attempts and for receive requests,
if we try to pay ourself (e.g. through a channel rebalance) the checks
in save_payment_info would prevent this and throw an exception.
By storing the PaymentInfos of outgoing and incoming payments separately in
the db this collision is avoided and it makes it easier to reason about
which PaymentInfo belongs where.

@f321x f321x changed the title lighting: fix self payments (e.g. rebalance) lightning: fix self payments (e.g. rebalance) Oct 20, 2025
@f321x f321x added the bug 🐞 label Nov 27, 2025
@f321x f321x force-pushed the fix_save_payment_info branch 3 times, most recently from df9760c to eedd9d2 Compare December 1, 2025 09:38
@f321x f321x marked this pull request as ready for review December 1, 2025 09:38
Comment on lines +416 to 418
if self.lnworker.get_payment_status(swap.prepay_hash, direction=lnutil.RECEIVED) != PR_PAID:
self.lnworker.delete_payment_info(swap.prepay_hash.hex(), direction=lnutil.RECEIVED)
self.lnworker.delete_payment_bundle(payment_hash=swap.payment_hash)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be done in both directions?
at least the delete_payment_info call?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, added this in 923d48f

f321x added 2 commits December 1, 2025 18:39
Allows storing two different payment info of the same payment hash by
including the direction into the db key.
We create and store PaymentInfo for sending attempts and for requests (receiving),
if we try to pay ourself (e.g. through a channel rebalance) the checks
in `save_payment_info` would prevent this and throw an exception.
By storing the PaymentInfos of outgoing and incoming payments separately in
the db this collision is avoided and it makes it easier to reason about
which PaymentInfo belongs where.
Allows replacing a saved `PaymentInfo` of `SENT` direction if the old
one is not yet paid.
This allows the user to retry paying a 0 amount invoice with different
amount if the previous attempt failed.
@f321x f321x force-pushed the fix_save_payment_info branch from eedd9d2 to df612fa Compare December 1, 2025 17:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants