Fix workflow migrations: remove redundant duplicates that break fresh-DB migrate - #67
Merged
Merged
Conversation
…-DB migrate The regenerated `0001_initial` snapshot (commit 8d9fdb2) already creates `FlowProject.workflow_context` and the `WorkflowRun` model. PR #55 later added a parallel branch of locally auto-generated migrations (`0002_flowproject_workflow_context`, `0003_workflowrun`, `0004_flowproject_hpc_target_flowproject_reference_and_more`, `0005_merge_20260524_1609`) that re-apply the same schema. On a fresh database `migrate` fails with `column "workflow_context" of relation "flow_projects" already exists`, so the backend crash-loops on startup. Remove the 4 redundant migrations, leaving the consistent chain `0001_initial -> 0002_flowproject_visibility -> 0003_flowproject_reference_hpc_target`, which reproduces the current models.py schema exactly. No data migration is needed: on already-migrated databases the deleted records become harmless phantom entries. Verified: `migrate` against a brand-new empty database applies all three workflow migrations cleanly with no DuplicateColumn error. Fixes #65 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Removes a redundant/duplicated branch of Django migrations in the workflow app that caused manage.py migrate to fail on a fresh database due to duplicate schema operations (e.g., workflow_context already existing), restoring a single consistent migration chain.
Changes:
- Deleted duplicate
workflowmigrations that re-applied schema already created by0001_initial. - Removed an empty merge migration that only existed to reconcile the duplicated migration branches.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| gui/workflow_backend/django-project/app/workflow/migrations/0002_flowproject_workflow_context.py | Deleted redundant migration that re-added FlowProject.workflow_context already present in 0001_initial. |
| gui/workflow_backend/django-project/app/workflow/migrations/0003_workflowrun.py | Deleted redundant migration that re-created WorkflowRun already present in 0001_initial. |
| gui/workflow_backend/django-project/app/workflow/migrations/0004_flowproject_hpc_target_flowproject_reference_and_more.py | Deleted redundant migration that re-added fields already covered by the remaining migration chain. |
| gui/workflow_backend/django-project/app/workflow/migrations/0005_merge_20260524_1609.py | Deleted empty merge migration that only existed due to the duplicated branch. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #65.
Problem
On a clean setup the backend crash-loops on startup —
manage.py migratefails with:This blocks every fresh environment (new clone, CI,
docker compose down -vreset, a new contributor's first run). Databases that were already migrated are unaffected, which is why it went unnoticed onmain.Root cause
The migration set is internally inconsistent.
0001_initialwas regenerated into a full snapshot in commit8d9fdb23("Track Django migrations and stop auto-generation") — it already createsFlowProject.workflow_contextand theWorkflowRunmodel. After that,mainwas a consistent 3-migration chain.PR #55 (
98af506a) then added a parallel branch of locally auto-generated migrations on top of that snapshot:0002_flowproject_workflow_contextworkflow_context0001_initial0003_workflowrunWorkflowRun0001_initial0004_flowproject_hpc_target_flowproject_reference_and_morehpc_target,reference,visibility0002_flowproject_visibility+0003_flowproject_reference_hpc_target0005_merge_20260524_160998af506adoes not changemodels.py, so these are not migrations for a new model change — they are duplicates of what the snapshot already builds (the0005_mergeis a leftovermakemigrations --mergeartifact). Startup runsmigrateonly, so the redundant ops execute against the schema0001_initialalready created → DuplicateColumn.Fix
Delete the 4 redundant migrations, leaving the consistent chain:
which reproduces the current
models.pyschema exactly (workflow_context,visibility,reference,hpc_target,WorkflowRun);0003_flowproject_reference_hpc_targetalready usesADD COLUMN IF NOT EXISTS.No data migration is needed: on databases that already applied the redundant migrations the deleted records become harmless phantom entries, and
migrateresolves the remaining single-leaf graph without error.Verification
Ran
migrateagainst a brand-new empty database with this branch's code:No DuplicateColumn, no crash loop. (Before this change, the same fresh-DB migrate fails at
0002_flowproject_workflow_context.)Notes / follow-ups
boxapp has an analogous redundancy (0002–0005 alter_pythonfile_category), but those areAlterFieldops that don't breakmigrate— left out of scope here as a follow-up cleanup.pytest/pytest-djangobuilds its test DB by running migrations, a minimal CI job running the backend test suite against a fresh Postgres would catch this class of bug automatically. Recommended as a separate task.