-
Notifications
You must be signed in to change notification settings - Fork 53
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
fix(sqlite): Prevent the execution of 'migrate' script if user_version==0 #2031
Conversation
You can find the image built from this PR at
Built from 54bdf98 |
Not sure I follow this fix - why would we consider nodes with |
I am not sure how to reproduce the original issue - I ran
then
And I get
In both executions, but no errors |
Ok, reproduced it - it needs some messages in the db (which makes sense, since it is caused by some constraint change)
wait to get messages in (or send your own non-ephemeral messages..)
THen I got
|
Thanks for the comments! I will look for a better solution. This cannot be merged indeed. |
No, I do not agree, it is actually executing migrations and failing to insert messages from |
Okay I see, in my case I saw that the migration scripts are being run properly, having the table empty:
|
Right, so this may have been caused by a migration that was interrupted? One impact is that potentially there might now be inconsistent schemas on upgraded nodes (since the migration failed) and a temporary backup tables that were never deleted. The fix would be to ensure that the migration is fixed and that impacted nodes can properly "get themselves out of the situation"? |
Migration 00004_extendPrimaryKey "broke it" Because it changes the PK to also inclide senderTimestamp, so when the user_version is wrong and the migrations try to re-run from scratch, since the 00004 already happened, the older migrations could have duplicates for the old PK (which was only id column) - we can have same id accross multiple messages after 00004 is applied since the PK consists of multiple columns So if the So the real issue is really actually missing |
My proposal would to
Execute all the above before migrations kick in, so when they do, we actually go from the right schema version THen keep this workaround in for a few releases to make sure people have enough time to migrate from 0.17.0 and then remove the check WDYT? |
I like the idea of checking the current schema, as you mentioned to me on Discord, and if the PK has three columns, then we assume that the version is 7, and we write 7 to the |
Btw, the schema version was set to 7 in the next commit: 4509f4f And therefore, started to be present from the |
…sion==0" This reverts commit 605b04e.
The main issue is that, when starting a node from scratch with for example 0.17.0, it doesn't set the SchemaVersion at all, although it is creating a database whose scheme reflects the expectations for version 7. In the PR I'm applying @vpavlin's suggestion: if |
🔔 The migration problem started to occur in version The reason why the migration scripts didn't start is because the migration.nim file was moved to a deeper folder but the relative path was not updated. That can be seen by looking for "migrations.nim" in https://github.com/waku-org/nwaku/compare/v0.13.0..v0.14.0 |
info "We found user_version 0 but the database schema reflects the user_version 7" | ||
## Force the correct schema version | ||
? db.setUserVersion( 7 ) | ||
return ok() |
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.
What happens in case where
- User is running v0.17.0
- We update schema in v0.21.0
- User updates to v0.21.0
IIUC the user_version gets set to 7
and then migrate
proc returns and the migration does not happen - which is wrong - right? IMO the migration should continue with corrected user_version
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.
Good point!
In this case, the migration should not happen because the database is using the schema version 7 (three columns in PK) but the user_version
value was 0.
If we update the schema in 0.21.0
we will need to revisit this logic of course. In fact, I think we need to modify this logic the next time we modify the schema somehow.
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.
Approving, as it seems like this will indeed fix the immediate issue. What bothers me though is that the CREATE script will still create a DB now with user_version 0
and this logic just updates it to 7
? I think the CREATE script itself should set the user_version to the correct schema number.
Thanks so much indeed for the feedback and comments guys! I recently applied a better approach, advised by @vpavlin, and we aim to have a future-proof solution. We'd need to keep this workaround during 10 version (?) I'll elaborate more on the actual problem in the related issue |
Ah, you are right, I haven't realized - if the DB is initialized from scratch, it will have user_version = 0, only if it got migrated it will have 7, so we should set the user_verion on init of the DB, which should prevent future issues with this |
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.
Tested the upgrade from "broken" v0.17.0 instance to this PR and it worked.
I think we are ok even if we merge it like this, but we need to resolve the cause (which seems to be not setting user_version
on DB init
) soon-ish
…cedure is not started (#2031)
Description
Given a
nwaku
node with Store-SQLite mounted, it will try to apply a migration script because theuser_version
present in the SQLite file is 0, whereas the expected version is 7.Changes
user_version
== 0 and the # of columns in PK is 3. In this case, we also enforce the SchemaVersion 7.How to replicate the issue:
In order to replicate the issue, the node should have a certain amount of messages stored in the database.
Use the next command, tailored by @vpavlin, to start the node, but change the docker image each time:
How to validate the fix:
Issue
closes #2027