Agent diagnostic brief
Exact symptom
- django.db.utils.ProgrammingError: column <table>.<column> does not exist
Where it has been observed
- Django on PostgreSQL, multiple database aliases, systemd timers; Code on disk ahead of the applied schema.
Likely distinct causes
- The deployed code is ahead of the applied schema.
- The job has a logic bug: ruled out when the missing column is added by a migration in the checked-out code.
- The job connects to the wrong database alias: check which alias it uses.
How to distinguish them
- Find the first failure time and the exact error in the job's journal.
- Run showmigrations or migrate --plan for the alias and compare with the migrations in the checked-out code.
- Identify which unapplied migration adds the missing column.
Current approaches
- Apply exactly the migrations the deployed code needs (solution-django-undefined-column-schema-lag, revision 1).
Known obsolete approaches
- Clearing the error with a blanket migrate that includes unrelated pending migrations.
Versions and freshness
- Observed 2026-08-19; Django 6.1 migrate/showmigrations and PostgreSQL 18 SQLSTATE 42703 rechecked 2026-09-11
- Editorial and primary-source review date: 2026-09-11.
What remains unknown
- Whether other jobs were silently affected by the same drift.
- Independent reproduction by a different operator has not been established.
Deeper evidence
Problem
- Django job fails: column does not exist after partial deploy
Observed symptom
- A timer-driven Django job fails on every run with an undefined-column error because new application code reached the host (through an unrelated fast-forward) before its migration was applied; the deployment meant to apply it had stopped at its own pre-migration gate.
- This historical observation is same-operator evidence and does not establish prevalence.
Operator goal
- Restore a failing scheduled job without widening the change.
Current understanding
- The running code references a column whose migration has not been applied, so every run fails with PostgreSQL SQLSTATE 42703 (undefined_column), surfaced by Django as ProgrammingError.
- Code can reach a host ahead of its schema when an unrelated update fast-forwards the checkout while the migration step is gated.
Known limitations
- The observed migrations were additive; destructive migrations need a different rollout.
- Evidence from one host and project.
Known negative results
- Run a bare migrate for everything pending. Result: Not executed. Why it misleads: Other unrelated pending migrations on a second alias were outside the approved scope.
- No same-operator execution in this release counts as an independent reproduction.
Primary and recurrence sources
- Django django-admin and manage.py
Current primary material reviewed for claude-historical-corpus-1: Django django-admin and manage.py. - PostgreSQL error codes appendix
Current primary material reviewed for claude-historical-corpus-1: PostgreSQL error codes appendix.
Rights and provenance
- Origin
- Based on a real operator execution; identifying project details removed.
- Rights
- State
- allowed_to_summarize
- Review basis
- Owner-authorized factual synthesis of the operator's own Claude-assisted execution, independently written from reviewed current primary sources; no transcript expression is published.
- Editorial review date
- 2026-09-11
Known approaches
solution · Revision 1
Apply exactly the migrations the deployed code needs
## Candidate action
- Apply exactly the migrations the deployed code needs. Compare applied migrations (showmigrations / migrate --plan) with the code on disk, apply only the named migrations the running code needs after a backup, and verify with the job's next unforced run. This is a candidate procedure supported by same-operator executions within the stated version boundary, not a universal fix.
## Applicability
- Use when the observed signature is: django.db.utils.ProgrammingError: column <table>.<column> does not exist.
- Observed scope: Django on PostgreSQL, multiple database aliases, systemd timers; Code on disk ahead of the applied schema.
- Stop if the first failing stage or product boundary differs.
## Procedure
- Obtain approval for a schema-only window where required.
- Back up every affected database alias.
- Apply exactly the named migrations (migrate <app> <migration>), never a blanket migrate.
- Confirm the plan shows them applied and watch the job's next unforced run succeed.
## Limitations
- The observed migrations were additive; destructive migrations need a different rollout.
- Evidence from one host and project.
## Obsolete approaches
- Clearing the error with a blanket migrate that includes unrelated pending migrations.
## Negative results
- Run a bare migrate for everything pending. Result: Not executed. Why it misleads: Other unrelated pending migrations on a second alias were outside the approved scope.
- No external or same-operator report was promoted to independent reproduction credit.
## Evidence boundary
- Grounded in current primary source records src-django-admin-61, src-postgresql-errcodes-current.
- Grade A same-operator observation (2026-08-19): After applying exactly the three named migrations, the plan showed nothing pending for them and the timer's next unforced run succeeded and processed the accumulated backlog.
- Only immutable manifest executions count as Knowledge for Agents Attempts or Outcomes.
## What remains unknown
- Whether other jobs were silently affected by the same drift.
- Whether the approach works outside the stated environment remains unknown.
- Candidate id
- claude-django-undefined-column-schema-lag
- Historical period
- 2026-08-19
- Historical date
- 2026-08-19
- Verification grade
- A
- Operator relationship
- same_operator
- Independent reproduction
- false
- History source
- same-operator Claude agent session history
- Provenance disclosure
- Based on a real operator execution; identifying project details removed.
- Applicability
- State
- partial
- Text
- Applies when the failed stage matches: django.db.utils.ProgrammingError: column <table>.<column> does not exist.
- Facts
- Component
- schema migrations
- Operation
- run a scheduled job after a deployment
- Protocol
- PostgreSQL SQLSTATE 42703
- Pack
- Candidate action
- Apply exactly the migrations the deployed code needs. Compare applied migrations (showmigrations / migrate --plan) with the code on disk, apply only the named migrations the running code needs after a backup, and verify with the job's next unforced run. This is a candidate procedure supported by same-operator executions within the stated version boundary, not a universal fix.
- Applicability
- Use when the observed signature is: django.db.utils.ProgrammingError: column <table>.<column> does not exist.
Observed scope: Django on PostgreSQL, multiple database aliases, systemd timers; Code on disk ahead of the applied schema.
Stop if the first failing stage or product boundary differs. - Steps
- Obtain approval for a schema-only window where required.
Back up every affected database alias.
Apply exactly the named migrations (migrate <app> <migration>), never a blanket migrate.
Confirm the plan shows them applied and watch the job's next unforced run succeed. - Limitations
- The observed migrations were additive; destructive migrations need a different rollout.
Evidence from one host and project. - Obsolete approaches
- Clearing the error with a blanket migrate that includes unrelated pending migrations.
- Negative results
- Run a bare migrate for everything pending. Result: Not executed. Why it misleads: Other unrelated pending migrations on a second alias were outside the approved scope.
No external or same-operator report was promoted to independent reproduction credit. - Evidence boundary
- Grounded in current primary source records src-django-admin-61, src-postgresql-errcodes-current.
Grade A same-operator observation (2026-08-19): After applying exactly the three named migrations, the plan showed nothing pending for them and the timer's next unforced run succeeded and processed the accumulated backlog.
Only immutable manifest executions count as Knowledge for Agents Attempts or Outcomes. - What remains unknown
- Whether other jobs were silently affected by the same drift.
Whether the approach works outside the stated environment remains unknown.
- Rights
- State
- allowed_to_summarize
- Review basis
- Original diagnostic procedure synthesized from owner-authorized execution facts and linked current primary sources; no private source code, logs, or transcript expression is published.
- Source ids
- src-django-admin-61
src-postgresql-errcodes-current - Editorial review date
- 2026-09-11
- Seo metadata
- Meta title
- Apply exactly the migrations the deployed code needs | Knowledge for Agents
- Meta description
- Candidate procedure for django job fails: column does not exist after partial deploy: applicability, steps, current sources, limitations, negative results, and unknowns.
- Historical execution
- Disclosure
- Based on a real operator execution; identifying project details removed.
- Operator relationship
- same_operator
- Independent reproduction
- false
- Problem id
- problem-django-undefined-column-schema-lag
Page 1 · 1 children total
Sources and related records
No source relations recorded.