2.17.4: "Error: Resource not found" on POST /login, migration failure precedes it (SQLite)

[MilanR11]

Describe the bug
After upgrading to 2.17.4 (via ghcr.io/muety/wakapi:latest), the container failed to start due to a migration error:

{"level":"ERROR","msg":"migration failed","name":"<migration right after nullify-empty-sub, likely sqlite_recreate_views-pre>","error":"duplicated key not allowed"}

After restarting the container, the app started successfully (login page loads fine, footer shows v2.17.4 @ sqlite3). However, logging in with existing credentials now returns "Error: Resource not found" on the POST /login response — the login page is re-rendered with this flash error instead of redirecting to the dashboard.

The user account still exists (confirmed via Sign Up form, which returns "Failed to create new user (username or e-mail already existing?)" for the same username).

Environment

• Wakapi version: 2.17.4 (previously running fine on an earlier version)
• Database: SQLite
• Deployment: Docker (ghcr.io/muety/wakapi:latest), behind nginx reverse proxy

Steps to reproduce

1. Run wakapi 2.17.3 or earlier with existing SQLite data
2. Update image to 2.17.4 and restart
3. Observe migration failure in logs on first start (see above)
4. Restart again — app starts, but login fails with "Resource not found"

Expected behavior
Login should succeed with valid credentials, and migrations should not fail/partially apply on existing SQLite databases.

[muety]

Hi @MilanR11, sorry for getting back to you so late. It looks like you have a duplicate entry, most likely in the users table. Can you do me a favor and send the results of running the following queries against your SQLite database?

select * from key_string_values where key regexp "^\d+-";

pragma table_info('users');

select id, email, auth_type, sub from users;

[muety]

Is this still relevant, @MilanR11?

[MilanR11]

Is this still relevant, @MilanR11?

Hello muety, sorry for late reply im on vacation. I come home next thurstday. Then i run queries and post you result.

[cnfw]

This has cropped up on my instance too.

I checked my SQLite database and got the following results for the queries posted

Query 1:

`select * from key_string_values where key regexp '^\d+-';`

20210213-add_has_data_field|done
20210221-add_created_date_column|done
20210411-add_imprint_content|done
20210806-remove_persisted_project_labels|done
20211215-migrate_id_to_bigint-add_has_data_field|done
20212212-total_summary_heartbeats|done
20220317-align_num_heartbeats|done
20220318-mysql_timestamp_precision|done
202203191-drop_diagnostics_user|done
20221016-drop_rank_column|done
20230219-add_astro_language|done
20230219-add_subscription_renewal|done
20231023-fill_last_branch|done
20220403-drop_user_project_idx|done
20260214-nullify-empty-email|done
20241220-share_activity_chart_flag|done
20250219-update_heartbeats_timeout|done
20250907-add_user_heartbeats_range_view|done
20250313-fix_browsing_category|done
20250802-fix_wsl_os|done
20251005-drop_duplicate_emails|done
20260103-add_webauthn_fields|done
20260111-sqlite_real_valued_time_column_durations|done
20260111-sqlite_real_valued_time_column_heartbeats|done
20260116-sqlite_fix_heartbeats_view_concat|done
20260524-sqlite_add_user_project_lang_index|done
20260214-nullify-empty-sub|done

Query 2:

`pragma table_info('albums');`

(no rows returned)

Query 3:

`select id, email, auth_type, sub from users;`

cnfw|[redacted email address]|local|

Relevant app log output:

2026-07-30 16:12:42.589 INFO potentially running migration name="20210202-fix_cascade_for_alias_user_constraint"
2026-07-30 16:12:42.589 INFO not attempting to drop and regenerate constraints on sqlite
2026-07-30 16:12:42.589 INFO potentially running migration name="20220403-drop_user_project_idx"
2026-07-30 16:12:42.590 INFO no need to migrate name="20220403-drop_user_project_idx"
2026-07-30 16:12:42.590 INFO potentially running migration name="20220930-drop_heartbeats_entity_idx"
2026-07-30 16:12:42.590 INFO potentially running migration name="20221002-fix_summary_id_types"
2026-07-30 16:12:42.590 INFO potentially running migration name="20221028-fix_heartbeats_time_user_idx"
2026-07-30 16:12:42.590 INFO potentially running migration name="20250425-add_durations_primary_key"
2026-07-30 16:12:42.591 INFO potentially running migration name="202601214-sqlite_recreate_views-pre"
2026-07-30 16:12:42.591 INFO potentially running migration name="20260214-nullify-empty-email"
2026-07-30 16:12:42.591 INFO no need to migrate name="20260214-nullify-empty-email"
2026-07-30 16:12:42.591 INFO potentially running migration name="20260214-nullify-empty-sub"
2026-07-30 16:12:42.591 INFO no need to migrate name="20260214-nullify-empty-sub"
2026-07-30 16:12:42.591 INFO running schema migrations
2026-07-30 16:12:42.985 ERROR migration failed error="duplicated key not allowed"

[ErlandssonA]

I also ran into this problem. No one found a fix for it yet?

[muety]

Sorry guys, let's get this fixed soon!

So, we have essentially five different candidates of unique indexes / constraints that could potentially yield a duplicated key not allowed error, which are:

• users.api_key
• users.email
• (users.auth_type, users.sub)
• heartbeats.hash
• (language_mappings.user_id, language_mappings.extension)

Mostly likely candidates are one of the users table indexes or the heartbeats hash. To further debug this, can you please:

• Run Wakapi in dev mode (ENVIRONMNET=dev or env :dev in config.yml) and paste the server logs again? This should the raw SQL statements issued by GORM, which will probably help pinpoint this issue
• Run the following to queries, then restart the server to see if the error persists:

  delete from key_string_values where `key` = '20260214-nullify-empty-sub';
  delete from key_string_values where `key` = '20260214-nullify-empty-email';

• If you don't mind, possibly even send me a copy of your SQLite database via email, so I can debug with the real data that causes the failure (will handle responsibly and delete right after my debugging efforts)