Release Gate Automation: A Green Build That Never Actually Asked the Database

A deploy pipeline can verify a great deal about a piece of code in complete isolation — that it compiles, that its types are internally consistent, that its own automated tests pass — without ever once asking the actual, live system the code is about to be pointed at whether it is genuinely ready to receive it. A release gate built specifically to close that gap has to do something categorically different from ordinary code-level checks: it has to reach out to the real target and ask it a direct, specific, falsifiable question — does this exact function, with this exact parameter list, actually exist on you, right now — rather than inferring an answer from anything the code alone can tell you.

The gate Centriu Loop built runs `npm run release:gate` after a release candidate already exists and before traffic is switched over to it — deliberately positioned at the one point in the sequence where blocking a release actually prevents the specific incident it exists to catch. It parses the application's own source code with a real TypeScript parser (not a simple text search) to extract every call the code makes to a database function, along with the exact, complete set of parameter names each individual call supplies.

Each extracted call is then checked against the real target database in two genuinely independent ways. The first is a direct query against the database's own catalog — the authoritative source of which functions exist and what parameters they declare, correctly aware of default parameter values and legitimate function overloading. The second is a live probe issued through the exact same request path an ordinary application call would use, authenticated as an anonymous caller — deliberately included because the database's own request-routing layer keeps a separate, cached view of the schema that does not always update in perfect lockstep with the catalog itself; a function can be entirely present and correct in the catalog while the routing layer serving real traffic has not yet picked up the change.

The gate's own final verdict is deliberately the WORSE of these two independent results, never simply an average or a majority. A catalog check that looks perfectly clean, combined with a live probe that comes back unreachable or clearly stale, is NOT treated as a pass — because a scenario where the catalog is technically correct but the layer actually serving traffic has not caught up is exactly the kind of gap a single-signal check would miss entirely. An unmeasurable result and a genuinely mismatched result each produce their own distinct, documented exit code, and both block the release outright. There is deliberately no bypass flag: overriding the gate's verdict requires directly editing the gate's own script and committing that edit under ordinary version control — a deliberately heavier, fully traceable act, not a flag flipped in the moment under pressure.

The gate's own correctness was proven against the exact incident it was built to prevent: a dedicated harness assembles both the pre-fix and post-fix database states in a real PostgreSQL instance, replays the exact code artifact from the day of the incident against both, and confirms all four resulting combinations behave correctly — critically, the twelve-parameter application code paired with the sixteen-parameter database correctly fails, naming precisely the four parameters the mismatch involves, exactly reproducing and catching the original incident.

A related, second-order gap was closed separately, in an older, DIFFERENT verification script that had existed since before this incident: Loop's own app-versus-database contract-checking matrix, which confirms the application's expectations line up with each of several possible database states. That script's own definition of "the current, newest database state" had been a hand-maintained, hardcoded list of migration numbers — meaning the very next new migration added to the project would have gone completely unnoticed by it, with the script continuing to report a full, clean pass while silently checking against a target that was already out of date. It now reads the actual migrations directory directly at run time instead, so its own definition of "current" can never again fall behind reality without the check itself failing first.

Before this gate existed, a deploy could rely entirely on the database's own catalog — a technically correct, but incomplete, witness — and miss that the layer actually serving live traffic had not yet caught up to match it. After the fix, the gate asks two independent witnesses every time, and if either one gives an unfavorable or unreachable answer, the release is blocked — exactly the design that would have caught the specific incident this gate was built in direct response to.

Centriu Loop's release process now runs a dedicated gate, positioned after a candidate exists and before traffic switches over, that checks every database function call the application makes against the live target two independent ways and blocks release on the worse of the two results, with no bypass short of a fully version-controlled edit — closing the exact class of gap that caused a real, roughly three-hour production incident, and hardening a separate, older contract-checking script that had its own risk of silently aging out of date.

This automation covers specifically Centriu Loop's own release-time gate checking the application-to-database RPC contract. 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 SQL commands inside migration files themselves before they run — a different check, at a different stage of the deploy pipeline, for a different class of risk entirely.

Checking a target's own catalog alone is simpler to build and correctly answers most of the question most of the time — the catalog genuinely is the authoritative record of what a database contains. It is not, by itself, a complete picture of what is actually SERVING live traffic at a given instant, because a request-routing layer's own cached view of the schema can lag the catalog by a real, measurable window. Checking both independently, and deliberately keeping whichever answer is worse rather than averaging or trusting either one alone, is the only version of the two that catches the specific, real gap between "the database technically has this" and "the database is currently serving this to real requests" — which is precisely the gap that caused the incident this gate exists to prevent.