Strange, there seems to be something invalid already with your current devices table.
Best solution here would be to stop Vaultwarden, make a copy of the database as backup.
Then open the database using a sqlite editor (GUI is the most easy for this one).
And then look at the devices table which has nothing filled in at the updated_at table.
Then you could add a custom date there and try to rerun the the upgrade.
An other option would be (if that works) is to remove all sessions for all users via the admin interface.
That should clear that table, but also forces you to do a re-login on all devices for all users.
<!-- gh-comment-id:1140807015 -->
@BlackDex commented on GitHub (May 30, 2022):
Strange, there seems to be something invalid already with your current `devices` table.
Best solution here would be to stop Vaultwarden, make a copy of the database as backup.
Then open the database using a sqlite editor (GUI is the most easy for this one).
And then look at the devices table which has nothing filled in at the `updated_at` table.
Then you could add a custom date there and try to rerun the the upgrade.
An other option would be (if that works) is to remove all sessions for all users via the admin interface.
That should clear that table, but also forces you to do a re-login on all devices for all users.
<!-- gh-comment-id:1141278038 -->
@angelbarrera92 commented on GitHub (May 30, 2022):
Added a dummy date in those row where were null; new errors appear in the same table while re-running the upgrade:
```
Running migration 20220302210038
Executing migration script 20220302210038/up.sql
[2022-05-30 15:22:23.227][vaultwarden][ERROR] Error creating database pool: DieselMig.
[CAUSE] QueryError(
DatabaseError(
__Unknown,
"NOT NULL constraint failed: devices_new.user_uuid",
),
)
```
Well, there are just two fields/columns which may be empty, and those are push_token and twofactor_remember all other fields should be filled.
If you have a records which do not have a user_uuid i would remove those records and try again
<!-- gh-comment-id:1141280798 -->
@BlackDex commented on GitHub (May 30, 2022):
Well, there are just two fields/columns which may be empty, and those are `push_token` and `twofactor_remember` all other fields should be filled.
If you have a records which do not have a `user_uuid` i would remove those records and try again
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @angelbarrera92 on GitHub (May 30, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2518
Subject of the issue
Running vaultwarden 1.24.0, then, trying to update to 1.25.0 (just changing the container tag image). It fails during container startup.
Seems like the migration sql sentences are not working fine in my setup.
Deployment environment
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden: DOMAIN, SIGNUPS_ALLOWED, ADMIN_TOKEN, SMTP_HOST, SMTP_SSL, SMTP_EXPLICIT_TLS, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD, SMTP_AUTH_MECHANISM
Steps to reproduce
I'm updating stopping the 1.24.0 and then starting 1.25.0 with the same configuration.
Expected behaviour
It updates :)
Actual behaviour
It fails with the following error:
Troubleshooting data
Non-default config:
1.25.0 start logs
@BlackDex commented on GitHub (May 30, 2022):
Strange, there seems to be something invalid already with your current
devicestable.Best solution here would be to stop Vaultwarden, make a copy of the database as backup.
Then open the database using a sqlite editor (GUI is the most easy for this one).
And then look at the devices table which has nothing filled in at the
updated_attable.Then you could add a custom date there and try to rerun the the upgrade.
An other option would be (if that works) is to remove all sessions for all users via the admin interface.
That should clear that table, but also forces you to do a re-login on all devices for all users.
@angelbarrera92 commented on GitHub (May 30, 2022):
Added a dummy date in those row where were null; new errors appear in the same table while re-running the upgrade:
@BlackDex commented on GitHub (May 30, 2022):
Well, there are just two fields/columns which may be empty, and those are
push_tokenandtwofactor_rememberall other fields should be filled.If you have a records which do not have a
user_uuidi would remove those records and try again