invoices: amp invoices bugfix.#9459
Conversation
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
bd6443b to
bef999d
Compare
|
why is this in 0.18.5? |
my bad. tagged for 0.19 now |
|
No, 0.18.5 is correct, we'll want it in there as it's an important bug fix. Going to re-tag. |
bef999d to
5bd4e66
Compare
03df39c to
72fc2e4
Compare
817bd45 to
5e120a0
Compare
|
This PR lead to the following feature request: #9463 |
guggero
left a comment
There was a problem hiding this comment.
Looks good to me. Left a question, since I'm missing a lot of context.
|
|
||
| case invpkg.CancelInvoiceUpdate: | ||
| return k.serializeAndStoreInvoice() | ||
| err := k.serializeAndStoreInvoice() |
There was a problem hiding this comment.
Couldn't we instead just call k.storeCancelHtlcsUpdate()? Which makes me think why we didn't do that in the first place? Maybe there's a reason? Missing too much context to be sure...
There was a problem hiding this comment.
good call, changed it makes absolutely sense to also persist the AMP state. We never changed the AMP related stuff when canceling an invoice, which is acutally the bug this PR is fixing.
1f689a7 to
8acdba7
Compare
| } | ||
| invoice, err := fetchInvoice( | ||
| invoiceNum, invoices, []*invpkg.SetID{&invSetID}, false, | ||
| invoiceNum, invoices, []*invpkg.SetID{setIDHint}, false, |
There was a problem hiding this comment.
Note that this changes behavior slightly as previously we'd pass in a pointer to an empty set id if the hint was nil whereas now we pass in the nil which isn't considered the same as an empty set id. PTAL here on how it is used within this package:
Line 1579 in 32cdbb4
There was a problem hiding this comment.
Yes I know this is a change to the logic however I think it was a bug in the first place, for the UpdateInvoice functionality. Because UpdateInvoice will always update a state. Normally we should always have the setID set for AMP invoices. However now that we cancel also the AMP invoice we need to make sure we consider all HTLCs according all setIDs if we cancel the invoice (in case multiple attempts are in the accepted state across multiple setIDs).
There was a problem hiding this comment.
Discussed this offline too. It's probably the best if we remove the HtlcSetBlankModifier altogether as it is not used anywhere.
| return err | ||
| } | ||
|
|
||
| // If this is an AMP invoice, then we'll actually store the rest |
There was a problem hiding this comment.
nit: i think this comment could be a bit more descriptive. A reader might be interested in why we're actually updating the amp htlc's in place.
There was a problem hiding this comment.
We are calling now k.storeCancelHtlcsUpdate() directly which makes sense since with might have updated the HTLCs after cancelling the invoice
We now cancel all HTLCs of an AMP invoice as soon as it expires. Otherwise because we mark the invoice as cancelled we would not allow accepted HTLCs to be resolved via the invoiceEventLoop.
8acdba7 to
715cafa
Compare
| } | ||
| invoice, err := fetchInvoice( | ||
| invoiceNum, invoices, []*invpkg.SetID{&invSetID}, false, | ||
| invoiceNum, invoices, []*invpkg.SetID{setIDHint}, false, |
There was a problem hiding this comment.
Discussed this offline too. It's probably the best if we remove the HtlcSetBlankModifier altogether as it is not used anywhere.
This PR makes sure that HTLCs in the accepted state will be canceled back if the invoice expires.
However as soon as a sub AMP invoice is settled we do not allow expiring the invoice anyways so canceling the invoice call will fail because we have a check for HTLC which are in the settled state and will return an error, never closing the invoice. This has the positive side-effect that all HTLCs in the accepted state will be cancelled via the
invoiceEventLoop. However we should definitly fix this behaviour for AMP invoices and also close them, hence not accepting any new payment to it.