Retry tmp bigint FK removal for deployments phase two

What does this MR do and why?

The post-deployment migration RemoveTmpBigintFkForDeploymentsPhaseTwo (20260805084521) was supposed to drop the foreign key fk_b9a3851b82_tmp (deployments.project_id_convert_to_bigint -> projects.id). It did not.

The migration is guarded by Gitlab::Database::MigrationHelpers::WraparoundAutovacuum#can_execute_on?(:deployments). That check returned false on production, because a wraparound prevention vacuum was running on the table, and the migration returned early. The guard is there on purpose: without it, this migration can hold up the post-deployment migration pipeline for hours. The intended workflow is to retry on a later deployment.

An early return counts as a successful run, so the migration is recorded in schema_migrations and will never execute again. The work needs a fresh migration.

This is the second retry for this foreign key. The first was !248679 (merged), which moved the removal out of DropTmpBigintIndexesAndFkForDeploymentsPhaseTwo (20260731085558) for the same reason.

The new migration

db/post_migrate/20260810085131_remove_tmp_bigint_fk_for_deployments_phase_two_retry.rb is a verbatim copy of the original body under a new class name. Same WraparoundAutovacuum include, same disable_ddl_transaction!, same milestone '19.3', same up and down.

up is idempotent. remove_foreign_key_if_exists returns early when the constraint is absent, so the migration does nothing anywhere the earlier attempt already succeeded, including self-managed installations.

down recreates the foreign key as NOT VALID, matching how AddBigintFkForDeploymentsPhaseTwo originally added it, so a rollback does not pay for a full table validation.

Both directions keep the wraparound guard, so this migration can be retried again if the vacuum is still running when it lands.

The original migration 20260805084521 is reduced to a bare no-op: milestone '19.3', empty up and down, and a comment explaining what happened and where the work moved. The WraparoundAutovacuum include and disable_ddl_transaction! are removed with it.

db/structure.sql is unchanged.

Migration testing on !248679 (merged) measured this same migration at roughly 4 to 6 seconds across the main, ci, and sec databases, with no change in database size.

Verification

rubocop -A passes on both migration files. reek reports only IrresponsibleModule, which every migration in that directory already trips.

No local database was available, so the migration was not run locally and no specs were executed.

The timestamp and its db/schema_migrations/20260810085131 sha256 were written by hand rather than generated with bin/rails generate post_deployment_migration. Worth a second look during review.

References

• Issue: #551602
• Previous attempt that was cut short: !248679 (merged)
• The attempt before that: !248030 (merged)

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.