-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
sqldb+invoices: fix incorrectly stored invoice expiries when using native SQL #8855
sqldb+invoices: fix incorrectly stored invoice expiries when using native SQL #8855
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
8a4ca1c
to
ea7f097
Compare
Question: Can you please elaborate on this? Is it because the precision will be lost when dividing the stored values by 1,000,000,000 to convert the nanoseconds into seconds? |
Since 64-bit nanosecond values are truncated to 32 bits, we lose 32 bits of information, making it impossible to accurately determine the original intended values. Please note that this issue only affects newly stored invoices and only impacts users who are using native SQL. |
-- Update the expiry to 3600 seconds (1 hour) for all records in the invoices | ||
-- table. This is needed as previously we stored raw time.Duration values which | ||
-- are 64 bit integers and are used to express duration in nanoseconds however | ||
-- the intent is to store invoice expiry in seconds. | ||
UPDATE invoices SET expiry = 3600; |
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.
🫡
ea7f097
to
1dd86ad
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.
Nice - tACK - LGTM ✅
tested the following:
Before this PR:
- Add invoice
- see that expiry watcher uses correct expiry
- but incorrect expiry persisted
- on restart, invoice immediately expired & payer cannot pay
Transitioning to this PR:
- on master, add the invoice.
- restart LND with this PR
- see that persisted expiry is 3600
- invoice is loaded & payer can pay
My main comment is around potentially matching the default expiry that LND actually uses for new invoices though, which is 24 hrs, not 1 hr.
c0fb4df
to
afe3d2e
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.
Thank you for the thorough review and insightful comments @ellemouton! Much appreciated :)
afe3d2e
to
a50d8bd
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 💾
@bhandras - just picked this up while going through some route blinding stuff: I see that for AMP invoices, our default is actually 30 days (instead of 24 hours like as for non-amp invoices). Is that potentially something we want to take into account? |
Good catch, thank you! Let me update the PR to also fix times for AMP invoices before we merge. Will re-req when done. |
a50d8bd
to
a779bc3
Compare
List of changes since last round:
PTAL :) |
b5661d6
to
eed34f8
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! 🚢
Previously, when using the native schema, invoice expiries were incorrectly stored as 64-bit values (expiry in nanoseconds instead of seconds), causing overflow issues. Since we cannot determine the original values, we will set the expiries for existing invoices to 1 hour with this migration.
Completely switch to the better maintained pgx driver.
eed34f8
to
053faa6
Compare
Previously, when using the native schema, invoice expiries were incorrectly stored as 64-bit values (expiry in nanoseconds instead of seconds), causing overflow issues. Since we cannot determine the original values, we will set the expiries for existing invoices to 1 hour with this migration.
Based on #8854 only the last 5 commits are part of this PR.