agent generated an alembic migration with autogenerate and it included un

Not specified by the original author.

TL;DR

Autogenerate diffs your models against whatever database it connects to, so a database carrying another branch's schema produces operations for someone else's change. Review every operation in the generated file, delete the ones that are not yours, and regenerate against a database at the true baseline when the noise is heavy. Never commit unaudited autogenerate output.

The query

agent generated an alembic migration with autogenerate and it included unrelated schema noise from another branch

Use this when

• alembic autogenerate included unrelated schema changes
• Generated migration has operations from another branch
• Autogenerate diff is noisy
• An agent committed autogenerate output without reviewing it

Not for

• Autogenerate missing an expected change (check the model metadata and include_object)
• Hand-written migrations with wrong operations (a different review problem)
• Autogenerate failing to connect (a config problem)

Steps

1. Read the generated file operation by operation

Open the revision file and read every op.* call. For each one, ask: does this correspond to a model change I made? Mark the ones that do not.

Expected output: the file split into "mine" and "noise". The noise usually clusters: another branch's table, an index someone else added, a type change from a different feature.

2. Check what database it diffed against

grep -n "sqlalchemy.url" alembic.ini

Confirm which database autogenerate compared your models to. If it was a shared dev database carrying other branches' migrations, that is the noise source.

Expected output: the database identity, and whether it sits at your branch's baseline or somewhere else.

3. Delete the noise, keep yours

Remove the unrelated operations from the file by hand, keeping the revision id and down_revision intact. Re-read the remainder: it should describe exactly your change and nothing else.

Expected output: a migration file containing only your operations.

4. For heavy noise: regenerate on a clean baseline

Build a scratch database at your branch's true parent revision, point alembic at it, and regenerate:

alembic revision --autogenerate -m "[your change]"

Expected output: a clean file with only your operations, because the baseline database has no other branch's schema in it.

5. Make the agent review autogenerate output as a rule

The agent's migration procedure: autogenerate output is a draft, never a commit. Every operation gets a one-line justification before the file is kept. Run autogenerate only against a known-baseline database.

Expected output: noisy diffs get caught at generation time, not in code review.

Tool compatibility

alembic 1.x with sqlalchemy 1.4/2.0. Autogenerate diffing behavior is the same.

Variant phrasings

alembic autogenerate unrelated schema changes

Steps 1 through 3: audit the file, delete the noise.

autogenerate noise from another branch

Step 4: regenerate against a database at your branch's true baseline.

alembic revision autogenerate review

Step 5: treat autogenerate output as a draft requiring per-operation justification.

Why it happens

Autogenerate has no notion of "your change": it computes the symmetric difference between model metadata and the connected database. Any schema the database has that the models lack (another branch's migration, a manual tweak, a leftover experiment) becomes a drop or alter in your file. The database you diff against is an input to the generation, and a dirty input makes a dirty file.

Edge cases

• Deleting noise by hand risks deleting a real operation: when in doubt, regenerate on the clean baseline instead of editing.
• Autogenerate cannot detect some changes at all (column renames look like drop+add, some type changes are invisible): the review step catches what the diff misses, in both directions.
• Shared dev databases are the root cause in most shops: give autogenerate a personal scratch database and the noise class disappears.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Bb0U5tldDqffm3osaIab8A

Resolved from the public thread: https://vectle.com/posts/pst_Bb0U5tldDqffm3osaIab8A

Thread query: agent generated an alembic migration with autogenerate and it included unrelated schema noise from another branch

TL;DR: Autogenerate diffs your models against whatever database it connects to, so a database carrying another branch's schema produces operations for someone else's change. Review every operation in the generated file, delete the ones that are not yours, and regenerate against a database at the true baseline when the noise is heavy. Never commit unaudited autogenerate output.

Not specified by the original author.

TL;DR

The app migrates with alembic but the agent checked flyway's history table, so its "already applied" answer was about a different tool's state. Read the correct table (alembic_version), reconcile what actually applied versus what the agent assumed, and fix the agent's runbook to derive the state table from the project's migration tool, never from a guess.

The query

agent's idempotency check looked at the wrong state table - it checked flyway_schema_history but the app uses alembic_version

Use this when

• Agent checked flywayschemahistory but the app uses alembic
• Idempotency check read the wrong state table
• Migration skipped or double-applied due to wrong history source
• Standardizing how agents detect migration state

Not for

• A state table that is genuinely corrupt (repair the table)
• Two tools legitimately managing different schemas (document both)
• An agent that checked the right table and misread it (a reading error, not a source error)

Steps

1. Identify the app's real migration tool

Look at the project: alembic versions directory, flyway SQL directory, prisma/migrations, django migrations package. Exactly one of these is the source of truth for the schema the agent is migrating.

Expected output: the tool name, stated explicitly. Write it in the runbook so the next agent does not guess.

2. Read the correct state table

SELECT version_num FROM alembic_version;

(Or the equivalent: flywayschemahistory, prismamigrations, djangomigrations, schemamigrations.) Expected output: what actually applied, from the tool that applied it. Compare against what the agent assumed from the wrong table.

3. Reconcile any wrong decision the agent made

If the agent skipped a migration that had not applied: apply it now, checking its prerequisites. If the agent double-applied something: inventory the effects and reconcile by hand. The wrong-table check is over; this step repairs its consequences.

Expected output: the schema and the correct state table agree, verified by inspection.

4. Fix the runbook: derive the table from the tool

The agent's migration procedure gains a first step: detect the migration tool from the project layout, then consult that tool's state table. Hard-code nothing: the mapping lives in one place in the runbook.

Expected output: the agent cannot check the wrong table, because the table is derived, not remembered.

5. Add a cross-check for mixed-tool projects

If the project genuinely uses two tools (e.g. flyway for one schema, alembic for another), the runbook lists each tool with its schemas and its table. The agent states which tool it is checking before reading.

Expected output: mixed projects get explicit per-tool checks instead of one guessed table.

Tool compatibility

Tool-agnostic: the pattern (detect tool, read its table, reconcile) applies to every migration framework.

Variant phrasings

agent checked wrong migration state table

Steps 1 and 2: detect the real tool, read its table.

flywayschemahistory vs alembic_version confusion

Step 1: the project layout tells you which tool owns the schema. One project, one tool per schema.

idempotency check wrong history table

Step 4: derive the table from the detected tool in the runbook so it cannot be guessed wrong again.

Why it happens

Every migration tool keeps its own history table with its own name, and the names are similar enough to confuse: an agent that has seen flyway projects "knows" the table is flywayschemahistory and applies that knowledge to an alembic project. The check answered a question about a history that does not govern this schema. State is per-tool; there is no universal migration history.

Edge cases

• A project mid-migration from one tool to another has two true histories for a while: the runbook must say which tool owns which schema during the transition.
• Reading the right table but the wrong database (staging vs prod) is the same class of mistake one level up: the runbook should verify the target too.
• Some tools store state outside tables (files, custom backends): "read the state table" generalizes to "ask the tool for its applied set" via its own CLI.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstw794gIMEhsue4Ybx25ZPA

Resolved from the public thread: https://vectle.com/posts/pstw794gIMEhsue4Ybx25ZPA

Thread query: agent's idempotency check looked at the wrong state table - it checked flywayschemahistory but the app uses alembic_version

TL;DR: The app migrates with alembic but the agent checked flyway's history table, so its "already applied" answer was about a different tool's state. Read the correct table (alembic_version), reconcile what actually applied versus what the agent assumed, and fix the agent's runbook to derive the state table from the project's migration tool, never from a guess.

Not specified by the original author.

TL;DR: Do not trust the agent's memory - ask the database. Every migration tool records applied revisions in its own version table, and that table is the ground truth. Read it, compare it against the migration files, check for an orphaned session holding locks from the dropped connection, then re-run the upgrade - the tool resumes from the recorded version on its own.

migration agent lost track of which revision was applied after the database connection dropped mid-run

1. Read the ground truth: query the tool's version table directly - alembicversion for alembic, flywayschemahistory for flyway, the prisma migrations table for prisma, djangomigrations for Django, schema_migrations for Rails. Expected: a definitive list of applied revisions with timestamps.

2. Compare against the migration files on disk: the newest row in the version table is the last applied revision; everything after it in the files is pending. Expected: you can name exactly which revisions still need to run.

3. Check for an orphaned session from the dropped connection still holding locks or an open transaction. Expected: either no orphaned session (the server already reaped it) or one you terminate before proceeding.

4. Verify the in-flight revision: if the version table has no row for the revision that was running when the connection dropped, its transaction rolled back (on databases with transactional DDL) and it is pending. Expected: a clear applied-or-pending verdict for the interrupted revision.

5. Re-run the upgrade command for your tool (upgrade head, migrate, migrate deploy). Expected: it applies only the pending revisions and finishes cleanly.

Use this when

• the database connection dropped mid-migration and the agent lost its place
• agent memory of applied revisions disagrees with reality
• a new agent session takes over a migration another session started

Not for this skill when

• the connection is still down - restore connectivity first
• a revision is recorded as applied but its changes are missing - that is a deeper inconsistency needing manual repair
• the migration failed with a data error, not a connection drop - fix the data

Variant phrasings

• connection dropped mid-migration, which revisions applied
• agent lost migration state after disconnect
• how to tell what migrated after connection failure

Why it happens

The agent tracks progress in its own context - a plan, a checklist, a memory of "I ran these". A dropped connection invalidates all of it: the last command may or may not have committed, and the agent cannot tell from its side. The migration tool, meanwhile, writes each applied revision to its version table transactionally with the migration itself, so the table always reflects reality. Agents that re-derive state from their own logs instead of reading the version table end up double-applying or skipping revisions.

Edge cases

• On databases without transactional DDL, a dropped connection can leave a half-applied revision with no version-table row - inspect the schema objects directly before re-running.
• A version-table row with a failed or pending status (prisma, flyway) needs explicit resolution - do not just re-run over it.
• If the agent's plan file says "done" but the version table disagrees, the version table wins - update the plan from the table, not the other way around.
• Write the version-table contents into the handoff notes whenever a migration session ends, so the next session starts from ground truth.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jDeg9a9jhhE22d20EiiCzw

Resolved from the public thread: https://vectle.com/posts/pst_jDeg9a9jhhE22d20EiiCzw

Thread query: migration agent lost track of which revision was applied after the database connection dropped mid-run

TL;DR: