[Regression on closed #498] Three migrations share the timestamp 1785200000000 again, so their run order depends on filename sorting

Aperta
  • Qualcosa non va?
#734 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
node.js, typescript
Ambito
build-system, database

Direzione di ricerca

Read the three migrations in src/database/migrations/ and the migration glob at src/database/data-source.ts:22; check whether any have already been applied in shared environments before renaming files and class suffixes. Add a CI check for duplicate timestamp prefixes as suggested, then verify the migrations have unique increasing timestamps and the check catches duplicates.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

Location — src/database/migrations/:

  • 1785200000000-AddBountySponsorIdStatusIndex.ts (class AddBountySponsorIdStatusIndex1785200000000)
  • 1785200000000-AddMissingLookupIndexes.ts (class AddMissingLookupIndexes1785200000000)
  • 1785200000000-AddSplitPercentageChecks.ts (class AddSplitPercentageChecks1785200000000)

Problem — The timestamp collision closed as #498 is present again: three distinct migrations declare the identical timestamp 1785200000000, which is both the suffix of the class name and the value TypeORM derives the sort key from. TypeORM sorts pending migrations by that numeric timestamp; for equal timestamps the resulting order is whatever order the glob in src/database/data-source.ts:22 (__dirname + '/migrations/*{.ts,.js}') yielded, i.e. filesystem/locale-dependent filename sorting. The migrations bookkeeping table then records three rows with the same timestamp, so migration:revert (which reverts "the last executed migration" by that key) has no deterministic notion of which of the three is last.

Why it matters — Two concrete consequences:

  1. npm run migration:revert can revert a different migration than the one that ran last, and repeated reverts can interleave the three unpredictably. Rolling back a bad deploy is exactly when this matters.
  2. Run order differing between environments (developer macOS checkout vs. a Linux CI container vs. a production image) means the three are not guaranteed to apply in the same sequence everywhere. Today the three happen to be mutually independent (two index migrations and one CHECK-constraint migration), so this does not corrupt anything yet — but the invariant "migration order is identical in every environment" is broken, and the next migration added at this timestamp, or any later migration that assumes one of these ran first, inherits a non-reproducible schema.

Reproduction / failure path

  1. ls src/database/migrations | cut -d- -f1 | sort | uniq -d prints 1785200000000.
  2. Run npm run migration:run on a database at the previous migration, then select timestamp, name from migrations order by id desc limit 3 — three rows share 1785200000000.
  3. npm run migration:revert — the migration chosen is not deterministically the last one authored.

Suggested fix

  • Renumber two of the three to unique, strictly increasing timestamps (e.g. keep 1785200000000, and move the others to 1785200000001 and 1785200000002), renaming both the file and the class-name suffix so file and class agree.
  • Only renumber migrations that have not yet been applied in any shared environment; if any of the three is already recorded in a deployed migrations table, update that row's timestamp/name in the renumbering migration's accompanying note rather than silently re-running it.
  • Add a CI check that fails when two files in src/database/migrations share a timestamp prefix. This is now the third timestamp collision in this directory (#322 for 1784800000000, #498, and this one), so a one-line guard is cheaper than filing it again: 
    ! ls src/database/migrations | cut -d- -f1 | sort | uniq -d | grep .
Lingua principale
TypeScript
Stelle
2
Fork
90
Merge medio
31m
PR unite (30g)
20

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MergeFi/backend

Tutte le issue di MergeFi/backend

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.