Drizzle's migrator decides what to run by timestamp, and never checks the hash

Drizzle's SQLite migrator decides whether to apply a migration by comparing timestamps. The hash column in its tracking table is written but never read.

The gate is one line in drizzle-orm/sqlite-core/dialect.js: a migration is applied when there is no last database migration, or when the last row's created_at is older than the migration's folderMillis. That mattered to us because Replicator's tracking table was a mess. It held 15 rows against 24 journal entries, and 12 of those rows stored migration tag names instead of sha256 hashes, because two different mechanisms had written to it over time. We were preparing to reconstruct that history by hand.

Reading the source made the reconstruction unnecessary. To make migrate a no-op on a database that already has the schema, you need one row whose created_at is at or after the newest journal entry's when. No squash, no deletes. Before writing that row we verify the database actually matches the snapshot (scripts/migrations-baseline.ts --verify-schema, comparing table and column names), because marking a migration applied without checking could silently leave an environment behind its schema.

The general rule: when a tool's bookkeeping looks corrupt, read the code path that consumes it before repairing it. The field you are worried about may not be load-bearing at all.

Receipt: Replicator (scripts/migrations-baseline.ts; node_modules/drizzle-orm/sqlite-core/dialect.js; FINDINGS.md, "Turso engine, Drizzle and SQLite").