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

Đang mở
  • Có gì không ổn?
#734 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
65/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, typescript
Lĩnh vực
build-system, database

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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 .
Ngôn ngữ chính
TypeScript
Star
2
Fork
90
Merge trung bình
31 phút
Pull request đã merge (30 ngày)
20

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MergeFi/backend

Tất cả issue của MergeFi/backend

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.