I fixed it once. Why did it collide again?

At the fix, 0041 was chosen as the next free number. But within that same hour, two other feature branches, each progressing independently, looked at the same trunk state and also concluded 0041 was next. One had used 0041 before the rename; the other merged right after.

Was it a coincidence that three files claimed 0041 on the same night?

Not really a coincidence — the direct condition was an "integration phase" where several long-running feature branches were being merged into trunk together. Normally merges land one at a time; that night three landed in quick succession, which widened the window for numbering collisions.

Did this cause any actual production damage?

No. All three were additive, idempotent SQL — things like add column if not exists or alter column ... set default — touching independent tables, so the outcome was the same regardless of application order.

Does renaming the file also fix its contents?

No. Renaming a file doesn't touch the comments inside it, so the renamed files kept header comments referencing the old numbers. Here too, right after renaming to 0042 and 0043, the heading comments inside still said 0040 and 0041 — a separate commit fixed that 40 minutes later.

console_name.sql Collided Again 58 Minutes Later

This article may contain affiliate links. Its content is not affected by advertising.

Starting with the conclusion

Fifty-eight minutes after fixing a migration-number collision by hand-renaming a file, the same number collided again. Two other feature branches had independently picked the same number and landed on trunk. The fix was the same as before — rename the later file — except this time there were three parties involved instead of two.

The symptom

supabase/migrations/ is managed with hand-assigned numbers — a plain sequence like 0001, 0002, and so on. One night, three files ended up sharing the same number.

0041_console_name.sql              ← merged 23:05
0041_school_postal.sql             ← merged 23:14 (a rename fixing an earlier 0040 duplicate)
0041_share_links_report_emailed.sql ← merged 00:12

All three were additive-only SQL — add column if not exists, alter column ... set default — touching entirely separate tables (app_settings, schools, share_links), so there was no production impact. The danger was the same as last time: latent uncertainty about which file runs first, which could vary by environment when applying migrations in numeric order on a fresh environment or staging.

The cause

Lining up the commit timestamps makes it clear what happened.

846f8ae 23:05:44  feat(admin): unify console display name          → 0041_console_name.sql
b4a2828 23:14:56  fix(migrations): resolve duplicate 0040 numbering → 0040_school_postal.sql renamed to 0041
2085eba 00:12:43  merge(integrate): zero-touch-automation           → 0041_share_links_report_emailed.sql
7b2746b 00:15:38  chore(migrations): clean up number collisions (0041 x3 → 0040..0043)

By the time 846f8ae (23:05) landed on trunk, 0041 already belonged to console_name. But b4a2828 (23:14) — meant to fix an earlier collision where two separate PRs (0040_share_links_report and 0040_school_postal) both claimed 0040 — renamed the later school_postal file to 0041 as “the next free number.” The branch doing this rename had no visibility into 846f8ae on trunk, so the very act of fixing a collision picked an already-taken number and created a new one.

Less than an hour later, a separate zero-touch-automation branch (merge commit 2085eba, 00:12) added and merged 0041_share_links_report_emailed.sql. Its source commit (4353ec2, 23:03) predated both renames, so it had independently picked 0041 on its own.

That night involved integrating several long-running feature branches into trunk together — a school-name matching UI, a document-signing subsystem, monthly report automation. Normally merges land one at a time; that night, four merges landed in a 70-minute window between 23:05 and 00:15. The pace of merging outran the “check the next number, then assign it” workflow, which is what let the collision recur inside a single hour.

The fix

7b2746b (00:15) cleaned up the remaining duplication. Of the three files, the one that had settled on trunk first — share_links_report_emailed — kept 0041, and the other two were renamed.

0041_school_postal.sql              → 0042_school_postal.sql
0041_console_name.sql               → 0043_console_name.sql
0041_share_links_report_emailed.sql → (unchanged)

Just like last time, not a single byte of file content changed. But as a side effect, the renamed files still carried header comments referencing the old numbers.

-- 0040: School postal code (...)     ← file is now 0042_school_postal.sql

--  0041: Unify console display name to "Kimiterasu Operations" (...)   ← file is now 0043_console_name.sql

That state lasted about 40 minutes until c17ff65 (00:55) noticed it in passing while doing unrelated schema.sql consistency work and fixed it. Renaming is a filesystem operation; it doesn’t propagate to the numbers written inside comments. “Renamed” and “the text inside was updated to match” are two separate pieces of work.

Prevention

Nothing in the source material for this incident mentions adding automated detection for number collisions. Both the first time (the 0035 duplicate) and this time, the fix was consistently the same: rename it by hand when you notice.

What shows through structurally is that the awareness of the collision risk and the actual timing of the next collision didn’t line up. The 23:14 rename was a reasonable response to the 0040 duplicate that had just been found, but it only holds for the trunk state at that exact moment. If two more merges land within the following 70 minutes, they take the just-picked number down with them. As long as numbering stays hand-assigned, the only information available for “what’s the next number” is always “the trunk state I last pulled” — and what number another branch is claiming in that same window is invisible to everyone until it merges.