[ssimpson89]

SUMMARY

Upgrading from a pre-25.6 release to 25.6.x fails during the migration Job when the database has any existing OAuth2 access tokens:

Applying oauth2_provider.0012_add_token_checksum...
ValueError: The following fields do not exist in this model, are m2m fields, primary keys, or are non-concrete fields: token_checksum

The access token model is swapped to main.OAuth2AccessToken, so the backfill in oauth2_provider.0012_add_token_checksum loads our model and calls save(update_fields=['token_checksum']) on every existing token. The token_checksum column on our model is added by main.0198_oauth2accesstoken_token_checksum_and_more, but nothing in the graph orders 0198 ahead of 0012. Django can schedule 0012 first, and when it does, the field is not in the historical model state yet. Fresh installs pass because the loop has no rows to save, so this only shows up on upgrades (or restores followed by migrate) with existing tokens.

The fix adds run_before = [('oauth2_provider', '0012_add_token_checksum')] to main.0198, the same approach main.0025 already uses for oauth2_provider.0001_initial. A test asserts that main.0198 is in the forwards plan of oauth2_provider.0012.

Design notes:

• No dependency cycle. The swappable dependency in 0012 resolves to main.__first__, and no main migration up to 0197 depends on an oauth2_provider migration past 0005.
• Safe for existing databases. On any install that reached 25.6.x both migrations are applied, and on older installs neither is, so the new edge cannot trigger InconsistentMigrationHistory. A failed upgrade like the one above leaves 0012 unapplied, so it also stays consistent.
• django-oauth-toolkit 3.4.1 skips this backfill for swapped models, but the published ghcr.io/ctrliq/ascender:25.6.3 image ships django-oauth-toolkit 3.3.0, which still runs the save. The ordering fix makes the migration correct regardless of which toolkit version is installed.

Testing:

• Reproduced on k3s: installed 25.4.0, created two personal access tokens, upgraded to 25.6.3. ascender-app-migration-25.6.3 failed at oauth2_provider.0012 with the error above.
• Restored the same 25.4.0 database and ran migrate in the 25.6.3 image with the patched 0198. main.0198 applied before oauth2_provider.0012, both succeeded, no unapplied migrations remained, and both tokens had token_checksum populated.

Workaround for affected installs until this ships: ascender-manage migrate main 0198 --noinput, then ascender-manage migrate --noinput.

ISSUE TYPE

• Bug, Docs Fix or other nominal change

COMPONENT NAME

• API

ASCENDER VERSION

25.6.3-23-gf8240942

[Copilot]

🟡 Changes recommended

The migration-ordering test fails under the API suite’s --nomigrations setting because the loader cannot find oauth2_provider.0012_add_token_checksum, causing NodeNotFoundError instead of validating ordering.

1 open issue

• Restore migration modules before checking migration ordering · New

What changed in this PR

This PR fixes OAuth2 token upgrade failures by ensuring Ascender adds the token checksum field before the OAuth provider migration attempts to backfill it.

Changes:

• Adds an explicit migration ordering constraint to main.0198.
• Adds a regression test asserting that ordering in Django’s migration graph.

File	Description
ascender/​main/​tests/​functional/​test_migrations.py	Adds a migration-order regression test.
ascender/​main/​migrations/​0198_oauth2accesstoken_token_checksum_and_more.py	Orders checksum field creation before the OAuth provider backfill.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

No active review issues are recorded for the migration-ordering fix.

No open issues 🎉

1 resolved since last review

• Restore migration modules before checking migration ordering

_{Review effort: Balanced}

[cigamit]

Duplicate of #1151 ?

[ssimpson89]

@cigamit yep, looks like it! I'll close this