-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Patch htlc attempt hash for legacy payments #9703
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
Patch htlc attempt hash for legacy payments #9703
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 Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 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 (
|
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.
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
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.
Thank you for the investigation,
LGTM - pending lint issue.
|
||
// Log a warning if the user is still using legacy payments, which has | ||
// weaker support. | ||
log.Warnf("Found legacy htlc attempt %v in payment %v", a.AttemptID, |
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.
Can legacy payments still be created with the latest LND release, or are these payments which are stuck inlight because of previous behaviour and we are just relaunching it every time ?
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.
yeah - it's another question that I will ask Kevin once he could restart his testnet node once this PR is merged. Weird we still have stuck payments.
Can legacy payments still be created with the latest LND release
No they can't, as stated in the commit msg,
For legacy payments, the hash field will be nil, and we need to use the
payment identifier instead. We have multiple ways to fix this:
A trivial solution is we can simply call `sharder.GetHash` in
`collectResult`, and pass this hash to `attempt.Circuit()`, which ends
up multiple methods taking the hash. This is bad as it's confusing why
the methods of `HTLCAttempt` need to take another hash value, while
itself already has the info via `HTLCAttempt.Hash`. We don't want an
exceptional case to influence our main flow.
We can then patch the field `HTLCAttempt.Hash`, and set it to the
payment hash if it's nil, which can be done in `collectResult`. This is
also less optimal as it means every htlc attempts, either legacy or not,
now need to bear this context.
The best way to do this is to patch the field in
`reloadInflightAttempts`. As we are sure any new payments made won't be
legacy, and the only source of legacy payments comes from reloading
existing payments.
// before MPP feature, the `Hash` field was not set so we use the | ||
// payment hash instead. | ||
// | ||
// NOTE: During the router's startup, we have a similar logic in |
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.
Instead of this comment could we use this function there as well ?
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.
or maybe we could patch in the db layer in fetchPayment
?
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.
Instead of this comment could we use this function there as well ?
You mean the GetHash
? Yeah we could use that, tho I think it's more clear this way. Plus it'd be better if we don't use shard tracker for non-AMP payments to make the flow clean for MPP.
or maybe we could patch in the db layer in fetchPayment?
Yeah it'd be nice if we did that initially. As for now it seems unnecessary as we won't create legacy payments, and those legacy payments should not be inflight anymore as they should have timed out years ago. Think it's weird we have this stuck payments still, will ask Kevin for more logs once he could start his testnet node.
routing/payment_lifecycle_test.go
Outdated
|
||
var r *switchResult | ||
|
||
// Assert the result is returned within 5 seconds. |
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.
instead of hard coded 5 seconds, just leave it out because the testTimeout
is a variable ?
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.
done
// before MPP feature, the `Hash` field was not set so we use the | ||
// payment hash instead. | ||
// | ||
// NOTE: During the router's startup, we have a similar logic in |
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.
or maybe we could patch in the db layer in fetchPayment
?
For legacy payments, the hash field will be nil, and we need to use the payment identifier instead. We have multiple ways to fix this: A trivial solution is we can simply call `sharder.GetHash` in `collectResult`, and pass this hash to `attempt.Circuit()`, which ends up multiple methods taking the hash. This is bad as it's confusing why the methods of `HTLCAttempt` need to take another hash value, while itself already has the info via `HTLCAttempt.Hash`. We don't want an exceptional case to influence our main flow. We can then patch the field `HTLCAttempt.Hash`, and set it to the payment hash if it's nil, which can be done in `collectResult`. This is also less optimal as it means every htlc attempts, either legacy or not, now need to bear this context. The best way to do this is to patch the field in `reloadInflightAttempts`. As we are sure any new payments made won't be legacy, and the only source of legacy payments comes from reloading existing payments.
b2bf87b
to
79ab2b2
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.
LGTM 🎉 thank you!
@bitromortac and I discussed offline, thinking we could use the SQL payment as an opportunity to permanently patch this nil |
Fix #9688 by making sure we always set the
Hash
field on legacy payments.