-
Notifications
You must be signed in to change notification settings - Fork 2.2k
[Part 7|*] Addressing TODOs left from the SQL payments implementation #10373
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
base: elle-payment-sql-series-new
Are you sure you want to change the base?
[Part 7|*] Addressing TODOs left from the SQL payments implementation #10373
Conversation
e00c320 to
4f1babb
Compare
4f1babb to
a6c9e12
Compare
47606dd to
01d9986
Compare
a6c9e12 to
d543390
Compare
|
Converage of the SQL store after this PR is merged: |
A context is added to failPaymentAndAttempt and its dependant function calls.
We make the TestDeleteNonInFlight and separate all the logic out for the duplicate payment test case. The deletion of duplicate payments is now tested in isolation only for the kv backend.
Previously we had db and application logic mixed on the db level. We now move the config option KeepFailedPaymentAttempts to the ChannelRouter level and move it out of the db level.
We add a test which tests the retrieval of first hop data like the first hop amount or the custom records on the route level.
We add a couple of additional tests to increase the unit test coverage of the sql store but also the kv store. We only create db agnostic unit tests so both backends are tested effectively.
2e6f53f to
fb82814
Compare
yyforyongyu
left a 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.
LGTM
We still have this question from Part 6, where we need to decide whether we need to use a timeout ctx or not?
| log.Debugf("Scanning finished, found %d inflight payments", | ||
| len(payments)) | ||
|
|
||
| // TODO(ziggie): Also check for payments which have no HTLCs at all |
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.
Why do we want to delete it? I think the payment in this case can be retried?
| "%v: %v", p.identifier, err) | ||
| // Optionally delete the failed attempts from the database. If we are | ||
| // configured to keep failed payment attempts, we skip deletion. | ||
| if !p.router.cfg.KeepFailedPaymentAttempts { |
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.
Nice 🎉
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.
agreeeeeed
| // called based on the configuration. | ||
| if tc.expectDeleteCalled { | ||
| m.control.On("DeleteFailedAttempts", | ||
| p.identifier).Return(nil).Once() |
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.
👍
|
|
||
| // Conditionally expect DeleteFailedAttempts to be | ||
| // called based on the configuration. | ||
| if tc.expectDeleteCalled { |
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.
nit: can use !tc.keepFailedPaymentAttempts
ellemouton
left a 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.
lgtm!
| "%v: %v", p.identifier, err) | ||
| // Optionally delete the failed attempts from the database. If we are | ||
| // configured to keep failed payment attempts, we skip deletion. | ||
| if !p.router.cfg.KeepFailedPaymentAttempts { |
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.
agreeeeeed
This PR cleansup some TODOs of the payment sql series, before tackling the dispatcher and the migration.