starred/pocket-id-pocket-id-2
1
0
Fork 0
mirror of https://github.com/pocket-id/pocket-id.git synced 2025-12-09 14:42:59 +03:00
Code Issues 116 Packages Projects Releases 10 Wiki Activity

🐛 Bug Report: v1.6.2 -> v1.6.3: failed to apply migrations #118

New Issue
Closed
opened 2025-10-09 16:27:25 +03:00 by OVERLORD · 8 comments
OVERLORD commented 2025-10-09 16:27:25 +03:00
Owner
Copy Link

Originally created by @plsnotracking on GitHub.

Reproduction steps

I rolled out my deployment from 1.6.2 -> 1.6.3?

Expected behavior

Update should be rolled out smooth.

Actual Behavior

N/A

Version and Environment

kubernetes - v.1.6.3

Log Output

2025/07/21 04:14:55 failed to run migrations: failed to apply migrations: Dirty database version 202507050
00000. Fix and force version.

Originally created by @plsnotracking on GitHub. ### Reproduction steps I rolled out my deployment from 1.6.2 -> 1.6.3? ### Expected behavior Update should be rolled out smooth. ### Actual Behavior N/A ### Version and Environment kubernetes - v.1.6.3 ### Log Output 2025/07/21 04:14:55 failed to run migrations: failed to apply migrations: Dirty database version 202507050 00000. Fix and force version.
OVERLORD commented 2025-10-09 16:27:28 +03:00
Author
Owner
Copy Link

@ItalyPaleAle commented on GitHub:

This is fixed in 1.6.4 which is building now, and should be out in a few mins.

If you've already upgraded to 1.6.3

You may need to run a SQL query to make sure the "dirty" state is cleaned. Please run this query if you're having issues with Pocket ID starting:

UPDATE schema_migrations SET "version"= 20250630000000, dirty=false

(The migration is idempotent so it's fine to re-run it)

@ItalyPaleAle commented on GitHub: This is fixed in 1.6.4 which is building now, and should be out in a few mins. ## If you've already upgraded to 1.6.3 You may need to run a SQL query to make sure the "dirty" state is cleaned. Please run this query if you're having issues with Pocket ID starting: ```sql UPDATE schema_migrations SET "version"= 20250630000000, dirty=false ``` (The migration is idempotent so it's fine to re-run it)
OVERLORD commented 2025-10-09 16:27:28 +03:00
Author
Owner
Copy Link

@Dmunch04 commented on GitHub:

This is fixed in 1.6.4 which is building now, and should be out in a few mins.

If you've already upgraded to 1.6.3

You may need to run a SQL query to make sure the "dirty" state is cleaned. Please run this query if you're having issues with Pocket ID starting:

UPDATE schema_migrations SET "version"= 20250630000000, dirty=false
(The migration is idempotent so it's fine to re-run it)

I had the same issues, and ran the query as you described, however now I'm gettings this error on startup

2025/07/22 13:14:33 failed to run migrations: failed to apply migrations: migration failed in line 0: -- Normalize (form NFC) all existing values in the database
DO $$
BEGIN
    -- This function is available only if the server's encoding is UTF8
    IF current_setting('server_encoding') = 'UTF8' THEN
        UPDATE api_keys SET
            name = normalize(name, NFC),
            description = normalize(description, NFC);

        UPDATE app_config_variables SET
            "value" = normalize("value", NFC)
        WHERE "key" = 'appName';

        UPDATE custom_claims SET
            "key" = normalize("key", NFC),
            "value" = normalize("value", NFC);

        UPDATE oidc_clients SET
            name = normalize(name, NFC);

        UPDATE users SET
            username = normalize(username, NFC),
            email = normalize(email, NFC),
            first_name = normalize(first_name, NFC),
            last_name = normalize(last_name, NFC);

        UPDATE user_groups SET
            friendly_name = normalize(friendly_name, NFC),
            "name" = normalize("name", NFC);
    ELSE
                RAISE NOTICE 'Skipping normalization: server_encoding is %', current_setting('server_encoding');
        END IF;
END;
$$ LANGUAGE plpgsql; (details: ERROR: column "nfc" does not exist (SQLSTATE 42703))
@Dmunch04 commented on GitHub: > This is fixed in 1.6.4 which is building now, and should be out in a few mins. > > ## If you've already upgraded to 1.6.3 > You may need to run a SQL query to make sure the "dirty" state is cleaned. Please run this query if you're having issues with Pocket ID starting: > > UPDATE schema_migrations SET "version"= 20250630000000, dirty=false > (The migration is idempotent so it's fine to re-run it) I had the same issues, and ran the query as you described, however now I'm gettings this error on startup ``` 2025/07/22 13:14:33 failed to run migrations: failed to apply migrations: migration failed in line 0: -- Normalize (form NFC) all existing values in the database DO $$ BEGIN -- This function is available only if the server's encoding is UTF8 IF current_setting('server_encoding') = 'UTF8' THEN UPDATE api_keys SET name = normalize(name, NFC), description = normalize(description, NFC); UPDATE app_config_variables SET "value" = normalize("value", NFC) WHERE "key" = 'appName'; UPDATE custom_claims SET "key" = normalize("key", NFC), "value" = normalize("value", NFC); UPDATE oidc_clients SET name = normalize(name, NFC); UPDATE users SET username = normalize(username, NFC), email = normalize(email, NFC), first_name = normalize(first_name, NFC), last_name = normalize(last_name, NFC); UPDATE user_groups SET friendly_name = normalize(friendly_name, NFC), "name" = normalize("name", NFC); ELSE RAISE NOTICE 'Skipping normalization: server_encoding is %', current_setting('server_encoding'); END IF; END; $$ LANGUAGE plpgsql; (details: ERROR: column "nfc" does not exist (SQLSTATE 42703)) ```
OVERLORD commented 2025-10-09 16:27:28 +03:00
Author
Owner
Copy Link

@ItalyPaleAle commented on GitHub:

Should be fixed by #762, apologies for this

@ItalyPaleAle commented on GitHub: Should be fixed by #762, apologies for this
OVERLORD commented 2025-10-09 16:27:31 +03:00
Author
Owner
Copy Link

@rjvdw commented on GitHub:

I encountered the same issue while upgrading. The migration failed with the following error:

2025/07/21 06:05:08 failed to run migrations: failed to apply migrations: migration failed in line 0: -- Normalize (form NFC) all existing values in the database
UPDATE api_keys SET
    name = normalize(name, 'nfc'),
    description = normalize(description, 'nfc');
UPDATE app_config_variables SET
    "value" = normalize("value", 'nfc')
WHERE "key" = 'appName';
UPDATE custom_claims SET
    "key" = normalize("key", 'nfc'),
    "value" = normalize("value", 'nfc');
UPDATE oidc_clients SET
    name = normalize(name, 'nfc');
UPDATE users SET
    username = normalize(username, 'nfc'),
    email = normalize(email, 'nfc'),
    first_name = normalize(first_name, 'nfc'),
    last_name = normalize(last_name, 'nfc');
UPDATE user_groups SET
    friendly_name = normalize(friendly_name, 'nfc'),
    "name" = normalize("name", 'nfc');
 (details: ERROR: syntax error at or near "'nfc'" (SQLSTATE 42601))

Running a postgresql 17 database

@rjvdw commented on GitHub: I encountered the same issue while upgrading. The migration failed with the following error: ``` 2025/07/21 06:05:08 failed to run migrations: failed to apply migrations: migration failed in line 0: -- Normalize (form NFC) all existing values in the database UPDATE api_keys SET name = normalize(name, 'nfc'), description = normalize(description, 'nfc'); UPDATE app_config_variables SET "value" = normalize("value", 'nfc') WHERE "key" = 'appName'; UPDATE custom_claims SET "key" = normalize("key", 'nfc'), "value" = normalize("value", 'nfc'); UPDATE oidc_clients SET name = normalize(name, 'nfc'); UPDATE users SET username = normalize(username, 'nfc'), email = normalize(email, 'nfc'), first_name = normalize(first_name, 'nfc'), last_name = normalize(last_name, 'nfc'); UPDATE user_groups SET friendly_name = normalize(friendly_name, 'nfc'), "name" = normalize("name", 'nfc'); (details: ERROR: syntax error at or near "'nfc'" (SQLSTATE 42601)) ``` Running a postgresql 17 database
OVERLORD commented 2025-10-09 16:27:34 +03:00
Author
Owner
Copy Link

@aclerici38 commented on GitHub:

I also got this. k8s, postgres v17.5, running distroless image

@aclerici38 commented on GitHub: I also got this. k8s, postgres v17.5, running distroless image
OVERLORD commented 2025-10-09 16:27:37 +03:00
Author
Owner
Copy Link

@ItalyPaleAle commented on GitHub:

@Dmunch04 what version of Postgres are you using? And how are you running it (if a container, what image)?

@ItalyPaleAle commented on GitHub: @Dmunch04 what version of Postgres are you using? And how are you running it (if a container, what image)?
OVERLORD commented 2025-10-09 16:27:37 +03:00
Author
Owner
Copy Link

@Dmunch04 commented on GitHub:

@ItalyPaleAle I'm running Postgres 12.5-alpine in a Docker container.

@Dmunch04 commented on GitHub: @ItalyPaleAle I'm running Postgres 12.5-alpine in a Docker container.
OVERLORD commented 2025-10-09 16:27:38 +03:00
Author
Owner
Copy Link

@ItalyPaleAle commented on GitHub:

@ItalyPaleAle I'm running Postgres 12.5-alpine in a Docker container.

It appears that the normalize function was added in 13, so you will need to upgrade your database to at least version 13.

Also note that PG 12 is EOL and unsupported at this stage. M

@ItalyPaleAle commented on GitHub: > @ItalyPaleAle I'm running Postgres 12.5-alpine in a Docker container. It appears that the normalize function was [added in 13](https://www.postgresql.org/docs/release/13.0/), so you will need to upgrade your database to at least version 13. Also note that PG 12 is EOL and unsupported at this stage. M
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
breaking
bug
documentation
feature
needs more upvotes
open to pull requests
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-2#118
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?