Skip to content

Handle missing user table in user condition validation - #141

Open
chosak wants to merge 3 commits into
mainfrom
fix/user-condition-migration-check
Open

chosak wants to merge 3 commits into
mainfrom
fix/user-condition-migration-check

Conversation

@chosak

@chosak chosak commented Oct 29, 2026

Copy link
Copy Markdown
Member

Django migrations currently fail with an unhandled exception if a user condition is defined; this is because the user condition validation queries the database, but the flags table will not have been created yet. The conditions are validated as part of this package's Django system checks.

As a fix, this PR modifies the condition so that it treats a missing user table as a failed validation. This will generate a warning, but not break in an unhandled way. Running migrations against an empty database will still show a warning:

System check identified some issues:

WARNINGS:
?: (flags.W002) Flag FLAG_NAME's 'user' condition has an invalid value.
        HINT: Unable to validate the user because the user table is not available. This may be because migrations have not been run.

As part of this change, this package's checks have been renamed from flags.E001 and flags.E002 to flags.W001 and flags.W002, to be consistent with Django's guidance on check naming:

Identifiers should follow the pattern applabel.X001, where X is one of the letters CEWID, indicating the message severity (C for criticals, E for errors and so).

Because these checks are generated as warnings, not errors, they should start with W.

This PR also includes unrelated ruff fixes to address formatting issues in Markdown code snippets.

Fixes #96. Thanks to @olitreadwell for this contribution. FYI @willbarton, we miss you.

olitreadwell and others added 3 commits October 29, 2026 09:39
validate_user queried the user model directly, so when the user table did
not exist yet (e.g. running migrate on a fresh database) the system check
crashed with a raw OperationalError/ProgrammingError instead of reporting
a warning. Catch those database errors and raise a ValidationError so the
check reports flags.E002 and migrations can proceed.
This package includes two Django checks that are generated at level
Warning, but are currently named like E001 and E002, implying Error.
The Django docs at https://docs.djangoproject.com/en/6.1/ref/checks/
say:

> Identifiers should follow the pattern applabel.X001, where X is one
> of the letters CEWID, indicating the message severity (C for
> criticals, E for errors and so).

This commit renames those checks to properly reflect their severity as
warnings, not errors.

@wpears wpears left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like a reasonable approach to me

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Setting user based flag conditions prevents migrations running on a fresh database

3 participants