Readiness probe core: live-DB schema-drift detection.
/health is a dumb liveness probe (no DB). /ready is the deploy gate — it
introspects the live database's column set and compares it against a
committed expected column map (what a fresh full migration-chain bootstrap
produces). A live DB missing an expected column is exactly the failure mode
that silently broke login when the auth schema gained account.deleted_at
via an in-place base-DDL edit instead of an appended migration: the deployed
code required a column an older bootstrapped DB never got, and a SELECT * +
JS deleted_at === null filter rejected every account. The /ready route
(http/common_routes.ts) turns that drift into a loud 503 so a deploy poll
rolls the release back instead of promoting code that can't authenticate
anyone. The discipline that prevents the drift is the frozen append-only
migration chain (auth/migrations.ts); this probe is the runtime net for a
lapse.
The check is intentionally column-presence only — not type / constraint /
index parity. Column names are DDL-deterministic and engine-portable, so a
map generated against PGlite at gen-time compares exactly against a live
Postgres at runtime; finer-grained parity would false-positive across the two
engines, and a false positive here means a rolled-back deploy — an outage you
caused. Full structural parity stays the dev-time cross-backend
schema-snapshot suite's job (testing/schema_introspect.ts). In-place *type*
changes (a column kept by name, retyped) are out of scope — they rely on the
query-time column-named failures instead.
This module is pure DB introspection + comparison: no HTTP, no filesystem, no
fixture-path knowledge. The route factory and the committed-fixture loader
live in http/common_routes.ts; the gen-time fixture-regeneration helper
lives in testing/schema_ready_fixture.ts.