agent ran 8 of 15 migrations before the deploy failed - no down migrations exist and production is half-migrated

TL;DR: Roll forward, not back. Query the migration state table to name exactly which 8 applied, fix whatever broke the deploy, then run the remaining 7 in order. If one of the 8 applied migrations is itself broken, write a new forward repair migration - don't invent a downgrade after the fact.

The problem as reported:

agent ran 8 of 15 migrations before the deploy failed - no down migrations exist and production is half-migrated

1. Name the applied 8. Query the tool's state table - e.g. for flyway: select version from flyway_schema_history where success = true order by installed_rank;. Expected: exactly 8 rows; you now know which migrations the database has.
2. Confirm the app still works against the half-migrated schema, and read the deploy failure - most of the time the deploy died for an unrelated reason (bad config, failed health check), not because of migration 8. Expected: a concrete, named blocker.
3. Fix the blocker. Expected: the deploy pipeline is green again apart from the pending migrations.
4. Run the migration command for the remaining 7. Expected: only migrations 9-15 run, in order; the tool reports the database up to date.
5. Verify: the state table shows all 15 applied, and the app boots and passes smoke tests against the full schema. Expected: no gaps, no errors.
6. Going forward: write down migrations for every future change (or adopt the expand/contract pattern) and rehearse the full sequence on a staging clone before prod. Expected: the next failed deploy has a tested path back.

Use this when

• A deploy died partway through a migration sequence.
• No down migrations exist and production is partially migrated.
• The only safe direction is forward.

Not for this skill when

• Down migrations exist and a rollback is genuinely safe - then roll back instead.
• One of the applied migrations corrupted data - stop, assess, and write a repair migration; don't just keep rolling forward blindly.

Variant phrasings

• migration failed halfway no rollback available
• half migrations applied deploy failed
• production half migrated no down migration
• resume failed deploy migrations forward

Why it happens

Migration runners apply in order and stop at the first failure. Without down migrations there is no automated path back to the pre-deploy state, so forward - completing the sequence - is the only safe direction.

Edge cases

• Migration 8 of 8 half-applied: check whether your tool wraps each migration in a transaction (postgres DDL is transactional, MySQL's is not) - non-transactional engines need manual reconciliation.
• The deploy failure was CAUSED by migration 8: write a repair migration first, then continue the sequence.
• Old and new app instances running against the half-migrated schema simultaneously: keep the schema backward compatible until the deploy finishes.

Provenance

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