Renumber api_keys epoch migration 0009 → 0010 (membership collision)

#27 in Riparion/arium — merged 2026-06-11

Follow-up to #26.

Problem

The 0009_api_keys_epoch migration added in #26 collided with the membership migrator's 0009_resource_members. Both arium migrators (migrator() and membership_migrator()) share the same _sqlx_migrations table and set ignore_missing(true). On any membership-enabled deployment, version 9 is already applied as "resource members", so when the core migrator gained its own version 9 (different checksum) it raised VersionMismatch(9):

migration 9 was previously applied but has been modified

…which .unwrap() turned into a boot panic / crash-loop. (Caught immediately on the QA deploy; the DB was never mutated — the failure happens during validation, before any migration is applied.)

Fix

Renumber the migration 0009 → 0010. Core (0001-0008) and membership (0009) share one monotonic version space, so 0010 is the next free version.

ignore_missing short-circuits validate_applied_migrations, and sqlx's apply loop has no out-of-order guard, so the core migrator applies version 10 cleanly even though membership's 9 and the consumer's higher-versioned domain migrations are already present.

No database ever recorded the old 0009 (it failed during validation, before applying), so the rename is safe on every existing deployment.

Validation

• cargo test -p arium --features sqlite,tokens,mfa --test api_tokens → 7/7 pass.
• Confirmed against sqlx 0.9 run_direct source: ignore_missing skips validation and the apply loop applies any un-applied version regardless of higher applied versions.

🤖 Generated with Claude Code