umami: Update script fails with new version of umami

1.37.0 has had it’s migration script updated. Users will need to pull the latest version, then run the following commands to resolve the 02_migration failure.

yarn prisma migrate resolve --rolled-back "02_add_event_data"
yarn prisma migrate deploy
yarn check-db

This issue appears to affect users who were using umami, prior to our migrations re-write. We have a PR up to resolve this issue.

PR: https://github.com/umami-software/umami/pull/1415

Looking a bit deeper into the history of the schema and my database, I can offer some clues (or at least a hypothesis) as to why my database, and perhaps others’, ran into some issues.

I’ve been running Umami for a couple of years now. As such, my database was initialized with sql/schema.postgresql.sql as it was a couple years ago. I noticed that 5e0c5643c6331d86f82b176de62087567d713cb7, which rewrote sql/schema.postgresql.sql to the form/style that is 001_init, doesn’t exactly match its predecessor – specifically, the account.username_unique index did not exist in the pre-001_init schema. So when #1232 came around and users had to manually mark the prisma migration as already being applied, that was technically a lie because the database didn’t actually match the schema of 001_init. That missing index didn’t appear to break normal Umami operation, but it did break applying 02_add_event_data today. At least, for me.

Hopefully this sheds some light on what’s happened and how we arrived here - Perhaps others can chime in and confirm whether their Umami installs were based on the older schema, if they have the username_unique index, etc and find some commonality (or prove that my breakage is unique).

same here, same errors.

MariaDB [umami]> select * from _prisma_migrations;
+--------------------------------------+------------------------------------------------------------------+-------------------------+---------------------+------+----------------+-------------------------+---------------------+
| id                                   | checksum                                                         | finished_at             | migration_name      | logs | rolled_back_at | started_at              | applied_steps_count |
+--------------------------------------+------------------------------------------------------------------+-------------------------+---------------------+------+----------------+-------------------------+---------------------+
| ffd07abd-08a0-4f5e-b24f-ff263c431a79 | 7d0d9ee6ac831d32d1e6ad0f5ea5ee09080c497a733d0203345e53358eadbd3e | 2022-07-21 22:33:28.968 | 01_init             |      | NULL           | 2022-07-21 22:33:28.968 |                   0 |
| fff31f07-81ce-449e-becb-a1713151ae8d | d6765f3ae2a8b9d2d0730452f4f277a03b2cc1a968ba9b01d34041a958dc46c7 | 2022-06-28 02:37:01.463 | 20220627184654_init |      | NULL           | 2022-06-28 02:37:01.463 |                   0 |
+--------------------------------------+------------------------------------------------------------------+-------------------------+---------------------+------+----------------+-------------------------+---------------------+
2 rows in set (0.035 sec)

Can either of you provide the following?

1. The output of your “yarn prisma migrate status” command.
2. The results of your _prisma_migrations table on your database.

yarn run v1.22.19 $ /app/node_modules/.bin/prisma migrate status Prisma schema loaded from prisma/schema.prisma Datasource “db”: MySQL database “umami” at “10.0.0.194:3306”

2 migrations found in prisma/migrations

Your local migration history and the migrations table from your database are different:

The last common migration is: 01_init

The migration have not yet been applied: 02_add_event_data

The migration from the database are not found locally in prisma/migrations: 20220627184654_init Done in 3.00s.

Can either of you provide the following?

1. The output of your “yarn prisma migrate status” command.
2. The results of your _prisma_migrations table on your database.