Upgrade 2026.5.7 → 2026.8.2 fails: InconsistentMigrationHistory — authentik_core.0064_..._idx applied before its 2026.8 dependency authentik_core.0063_actor / authentik_rbac.0011

Describe the bug

Upgrading from 2026.5.7 to 2026.8.2 (docker compose) puts the server container into a permanent crash loop. Django's migration consistency check fails before any migration is applied:

django.db.migrations.exceptions.InconsistentMigrationHistory:
Migration authentik_core.0064_user_authentik_c_usernam_2f0e4b_idx is applied
before its dependency authentik_core.0063_actor on database 'default'.

(also seen against authentik_rbac.0011_initialpermissionspermission.)

The Rust server wrapper then reports the backend gone and the container restarts, looping indefinitely (RestartCount climbed to 16 in ~1 minute):

{"filename":"src/server/mod.rs","level":"warn",...,"code":"ExitStatus(unix_wait_status(256))","event":"server has exited"}
{"filename":"src/main.rs","level":"error",...,"event":"authentik encountered errors"}  the server has exited unexpectedly

Root cause (analysis)

The 2026.5 and 2026.8 migration branches appear to have diverged:

• authentik_core.0064_user_authentik_c_usernam_2f0e4b_idx shipped in the 2026.5 line and is applied in our DB (applied during the 2026.5.7 upgrade).
• authentik_core.0063_actor and authentik_rbac.0011_initialpermissionspermission are 2026.8-only migrations, not present in the 2026.5 graph, so they are not applied in a DB coming from 2026.5.x.
• In 2026.8, 0064_..._idx depends on 0063_actor — a migration numbered lower than one already applied from the 2026.5 branch. Django's check_consistent_history therefore fails ("0064 applied before its dependency 0063").

i.e. a released 2026.5 migration effectively gains a back-dependency on a newly-inserted, lower-numbered 2026.8 migration. --fake-applying 0063_actor is not a safe workaround because it is a real schema change (creates the actor table).

Migration history from the affected DB:

 app            | name                                     | applied
----------------+------------------------------------------+---------------------------
 authentik_rbac | 0010_remove_role_group_alter_role_name   | 2026-03-14 12:28:25+00
 authentik_core | 0064_user_authentik_c_usernam_2f0e4b_idx | 2026-09-10 00:20:07+00   (from 2026.5.7)
 (authentik_core.0063_actor and authentik_rbac.0011 are NOT applied — 2026.8-only)

To reproduce

1. Run 2026.5.7 (a DB that has authentik_core.0064_..._idx applied but not 0063_actor).
2. Upgrade to 2026.8.2 (bump image tags, docker compose pull && up -d).
3. server crash-loops on the InconsistentMigrationHistory above.

Expected behavior

The 2026.5.7 → 2026.8.2 upgrade migrates cleanly. The 2026.8 migration graph should not make an already-released 2026.5 migration depend on a newly-inserted, lower-numbered migration (a merge migration or corrected dependency is likely needed).

Version and Deployment

• authentik 2026.5.7 → 2026.8.2 (fails)
• Deployment: docker-compose
• PostgreSQL 16-alpine; Python 3.14 (per traceback path)
• Upgrade history reaching 2026.5.7: 2025.10.2 → 2025.10.4 → 2025.12.4 → 2026.2.1 → 2026.2.2 → 2026.2.3 → 2026.2.4 → 2026.2.6 → 2026.5.6 → 2026.5.7

Workaround used

Reverted the image tag to 2026.5.7 and restarted. Because the failure is in the migration planning/consistency phase (before anything is applied), the DB is untouched and 2026.5.7 comes back cleanly with no DB restore needed.