Bring the migration snapshot back in step with the schema

[NathanTarbert]

What this changes

Regenerates the drizzle snapshot so it agrees with core.ts again, which gets the migrations job green.

Fixes #91.

Two fields moved in server/src/db/schema/core.ts in #87 and meta/0005_snapshot.json was not regenerated alongside them, so drizzle-kit generate has been writing a migration nobody asked for and the drift probe has been failing on the dirty tree — on main, and on every branch cut from it since.

	core.ts	meta/0005_snapshot.json before this
accounts.issuer	nullable (:92)	notNull: true
sso_providers.user_id FK	on delete set null (:169)	cascade

The DDL is a no-op, and that is the point worth reviewing

The three statements look like a schema change and are not one. No deployment is in the state the old snapshot described:

• accounts.issuer does not appear in 0000_schema.sql at all. 0002_sign_in.sql:19 adds it nullable, 0003_backfill_account_issuer.sql fills it, and SET NOT NULL was never applied anywhere. DROP NOT NULL therefore drops a constraint that does not exist, which Postgres accepts.
• 0004_identity_provider_outlives_its_registrar.sql already dropped and re-added the sso_providers foreign key with ON DELETE set null. Re-landing it puts it back on the constraint it already has.

The migration file opens with a comment saying exactly that, so nobody reading drizzle/ later goes hunting for the schema change it was written for.

Editing meta/0005_snapshot.json by hand was the alternative and would have avoided the pointless DDL. Regenerating won because it is the tool's own output rather than a hand-edit of a generated file, and because 0006 leaves a readable record of when the two came back into agreement. Happy to switch if you would rather the snapshot were repaired in place.

Where it runs

• New state that outlives a request? None.
• What happens on the second replica? Nothing differs. No runtime code is touched, and the DDL changes no database.
• Anything serialised? The migration runs through the same drizzle-kit migrate step every other one does.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No.

Boundary and audit

• N/A. No gateway, policy, or audit path touched.

Changelog

No line. A deployment behaves identically afterwards — the statements are no-ops and there is nothing for an operator to do or know.

Proof

Both steps the migrations job runs, reproduced locally against this branch:

$ bunx drizzle-kit check --config=drizzle.config.ts
Everything's fine 🐶🔥

$ bunx drizzle-kit generate --config=drizzle.config.ts --name=ci_drift_probe
No schema changes, nothing to migrate 😴

The probe writes nothing now, so the tree stays clean and the job passes. On main the same command writes a file, which is the failure.

The generated meta/0006_snapshot.json and _journal.json needed biome format before format:check would pass, matching how the existing snapshots in drizzle/meta are stored. Formatting them does not reintroduce drift — the probe was re-run afterwards and still reports no changes.

Rest of the suite:

• bun run format:check — clean, 364 files.
• bun run lint — 27 warnings, 1 info, identical to unmodified main.
• bun run typecheck — clean across app, server and worker.
• bun test — 780 pass, 5 skip, 79 fail, 864 tests across 91 files, exactly the unmodified main baseline on this machine. The 79 are the database integration tests, which need a Postgres this machine does not have and fail the same way on a clean main; the CI tests job runs pgvector for them.

Worth landing before #92 and the fix for #88 item 1, since both are sitting red on this same inherited check.

One thing for a separate conversation

The drift probe caught this when it happened and the merge went through anyway, so there may be a required-check setting to look at. That is a repo setting rather than a code change, so it is not in this PR.

[davidmckayv]

Superseded, and only by minutes: #90 landed the same repair at 17:54 and you opened this at 17:44, so we were both on it without knowing. Sorry for the wasted work.

Your diagnosis is the better-written one and it is right in a detail mine glossed: the DDL really is a no-op, because SET NOT NULL was never applied anywhere and 0004 had already put the foreign key on set null. I said 'repairs the snapshot chain' and left it there; the table of what core.ts says against what the snapshot said is the version somebody debugging this in six months actually needs.

You also reached the same conclusion on the alternative, which is worth recording: regenerating beats hand-editing meta/0005_snapshot.json, because it is the tool's own output and it leaves a dated record of when the two came back into agreement.

Closing this one rather than #90 only because #90 was already merged and carries six other fixes with it.