mirror of
https://github.com/go-admin-team/go-admin.git
synced 2026-09-24 11:08:09 +00:00
zhangwenjian
d6e2c02fda
The process started, both probes passed, and the first sign that the schema did not match was a login failing with a driver-level encoding error - go-admin#919, where an operator upgraded the binary and restarted the API without running migrate. Nothing between those two events had an opinion about the schema. Readiness is where this belongs. Liveness asks "restart me", and a process whose database is on the wrong schema comes back to the same schema. Readiness asks "send me requests", and the answer is no. A rolling update then stalls at the deploy - new instances never become ready, the old ones keep serving - rather than at somebody's login, and running migrate clears it without a restart because the check is evaluated per request. Any tenant database being behind fails the check, not only the one being served: migrations are applied to every database in one run, so one behind means that run did not finish, and serving the rest would let a half-applied deploy look like a partial success. A missing sys_migration table is nothing applied rather than an error. That is a first deploy, where every migration is pending and the operator can act on being told so. The one test that matters is the one that cannot be written normally. The registry is filled by init() in packages cmd/api does not import, so a test that imported them to look at it would pass whatever the real binary links - and a binary that links none of them gives a check that reports every database current, forever, with every other test here still green. TestTheServingBinaryLinksTheMigrationRegistry asks the build instead, with a negative control so that a query matching everything fails rather than passes. Closes #920.