-
Notifications
You must be signed in to change notification settings - Fork 137
tapdb: error on dirty database versions #1826
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: main
Are you sure you want to change the base?
tapdb: error on dirty database versions #1826
Conversation
Summary of ChangesHello @ViktorT-11, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly improves the reliability of database operations within Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
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.
Code Review
This pull request introduces a crucial safety check to prevent the application from starting with a dirty database, which could happen if a migration fails. The change correctly identifies a dirty state by checking the flag returned by the migration library and exits with an informative error. The implementation is sound. I've added one minor comment regarding string formatting to improve readability and align more closely with the style guide's examples.
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 pointing this out and fixing it!
Might be worth adding a regression test to tapdb/migrations_test.go
if not too expensive.
Add checking of the error returned by the `migrate.Version` function in `tapdb/migrations.go`.
Add a check during startup to ensure that the database version is not dirty (i.e., the last migration did not complete successfully). If it is dirty, the application will exit with an error. This is done to resolve a bug that would occur when the **latest** migration failed. In that scenario, the database version would correctly be marked as dirty and exit with an error. However, under `sqlite` database backends, when `tapd` was restarted, the dirty database version would never be checked and `tapd` would start up normally, despite the database being in a dirty state. This is due to the check here: https://github.com/lightninglabs/taproot-assets/blob/0ddb08670f59e41e7edb2925a49df18d2124598e/tapdb/sqlite.go#L206-L213 In that scenario, since no migration is needed the migrate library is never called to perform any potential migration. And since the dirty check is normally done in the migrate library during a migration, it is never performed in that scenario.
50894ac
to
8c3ff91
Compare
Thanks for the review @ffranr! I added an I do think this added test adds value and proves the need for this PR until lightninglabs/migrate#3 is used though! |
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.
Looks good, consider adding a release note for this
Also an extra note: We're adding this to the v0.7.0-rc2 scope so it's ok to merge into |
This PR fixes 2 issues in the current handling of database migrations in
tapdb
:The main issue resolved is that we add a check during startup to ensure that the database version is not dirty (i.e., the last migration did not complete successfully). If it is dirty, the application will now always exit with an error.
This is done to resolve a bug that would occur when the migration with the latest migration version failed. In that scenario, the database version would correctly be marked as dirty and exit with an error. However, under
sqlite
database backends, whentapd
was restarted, the dirty database version would never be checked andtapd
would start up normally, despite the database being in a dirty state. This is due to the check here:taproot-assets/tapdb/sqlite.go
Lines 206 to 213 in 0ddb086
Secondly, we add checking of an error that was previously unchecked.