Deploy Sequencing Automation: A Rule Written in Prose Is Not a Rule at All

Writing down "apply every migration before deploying code that depends on it" in a deploy guide correctly identifies the right rule — the two really do need to happen in that order, every time. But a sentence in a document has no mechanism connecting it to what actually happens at deploy time: it depends entirely on a person remembering it, at the right moment, under whatever pressure or distraction a real deploy carries. The gap between a correctly-stated rule and an actually-enforced one is invisible for as long as the rule is never actually broken — and becomes a real production outage the first time it is.

A build pipeline's own checks — does the code compile, does it type-check, do the automated tests pass, does the deployed artifact match the intended commit — are all genuinely valuable, and none of them, even taken together, can tell you whether the LIVE DATABASE the code is about to run against actually has the specific function shape the code expects. That is a fact about the deploy TARGET's own current, real state, not about the code itself — and a pipeline that never asks the target a direct question ("does this specific function, with this specific parameter list, actually exist on you right now") has no way to catch a mismatch between the two, no matter how many other things it correctly verifies.

A Centriu Loop deploy shipped code calling the ledger's own movement-recording function with sixteen named parameters — the function's new, intended shape. The live production database, at that moment, still ran an older, twelve-parameter version of the identical function, because only one of the two migrations the new code required had actually been applied; the second had been written and prepared, but the step to actually run it against production had been skipped.

The underlying database's own query layer resolves precisely which function a call is asking for by matching the caller's complete set of supplied parameter NAMES against a function's own declared parameter names — arity and typing are not what determines the match. Four of the sixteen names the new code supplied did not exist on any function the live database actually had, so the call matched nothing at all, failing immediately with a distinct "function not found" signal rather than any softer or more ambiguous symptom. Because every one of Loop's cashback actions — launching a credit, redeeming it, adjusting a balance, reversing a mistake — passes through this identical shared function, all of them failed together, for roughly three hours, until the mismatch was diagnosed and the missing migration applied.

The diagnosis itself was replicated directly, not just reasoned about after the fact: a real PostgreSQL 16 database was rebuilt to match exactly the pre-fix production state (every prior migration applied, specifically excluding the two the deploy actually needed), and the identical sixteen-parameter call was issued against it — reproducing the exact same failure, and confirming precisely which four parameter names the live function did not yet recognize. The fix itself applied the one missing migration on its own, verified in a dry run beforehand to touch exactly that one migration and no others, restoring the function to its full sixteen-parameter shape with no application code needing to change at all — the code had already been correct from the moment it was written; only the database's own state had lagged behind it.

A closely related, smaller correction landed the same night: the incident's own changelog entry had originally been dated using a mix of time zones — the deploy itself recorded in local time, the migration timestamps recorded in UTC — which made a genuinely three-hour gap between the break and the fix read, at a glance, as if it spanned into the following day. Every timestamp in the record was corrected to a single, explicitly-labeled time zone, so the true, short duration of the outage is what the record actually shows.

Before the fix, new application code, cut specifically for a database function's NEW sixteen-parameter shape, was deployed while the live database's own function was still in its OLDER, twelve-parameter shape — like a new key cut for a lock that had not actually been rekeyed yet. The key did not almost fit; it matched nothing at all, and every door depending on that one lock stopped opening. After the fix, the missing migration brought the lock's own shape up to match the key that had already been cut, and every one of those doors opened again.

The specific migration behind this incident is applied and verified against production, Loop's ledger-movement function matches its own application code's expectations again, and the incident's own record is corrected to a single, accurate time zone — closing an outage where a documented deploy-ordering rule existed only in prose, with nothing in the deploy process itself checking that it had actually been followed.

This automation covers specifically the root cause and correction of one production incident in Centriu Loop's own deploy process — a migration-ordering gap between application code and a live database function. It is a distinct mechanism from this pillar's separate wave 71 page on Loop's deploy-time SQL-safety text scanner, which catches dangerous COMMANDS in migration text before deploy — a different check, at a different stage, for a different class of risk. The dedicated release gate built specifically to prevent a recurrence of THIS incident is covered on its own companion page.

Documenting the correct order of operations in a deploy guide costs almost nothing to write, and it is entirely correct as GUIDANCE — the rule it states really is the right one. Its weakness is that following it depends entirely on a person remembering it correctly, under real conditions, every single time, with no fallback if they don't. Building an automated check that directly confirms, against the live target itself, whether the required migration has actually landed before deploying dependent code closes that gap regardless of what any individual deploy remembers or forgets — which is exactly the shape of the gate this incident motivated, covered on its own companion page.