Production Inventory Silent Partial-Failure Automation: A Green Exit Code Is Not the Same as a Complete Report

A script built to produce several independent sections of a report — one query per section, printed in sequence — commonly continues to the next section even if one query fails, rather than aborting the entire run over a single broken part. That design choice is often the right one: a partial report with eight working sections and one error is more useful than no report at all. The risk specific to this design is what happens to the SCRIPT'S OWN exit code, and to whoever reads the report afterward: if the exit code still reports overall success, and the broken section's error message looks similar enough to ordinary diagnostic output, a report containing a genuine, unaddressed failure can be read, cited, and relied upon as if every section in it had actually succeeded.

Centriu Loop maintains a dedicated, read-only production inventory script specifically to measure and report the real, live state of the module's own access configuration — a genuine, direct verification against the actual running database, deliberately built to answer questions about production with more certainty than reading migration files or application code alone could provide. The script's design produces several independent sections in sequence, each answering a distinct question.

One specific section, meant to enumerate which organizations and roles currently hold which module-level permissions, joined a permissions table to a separate modules table using a column named `modules.slug` — a column that, in the actual production schema, does not exist on that table at all. Running that query against the real database produced a genuine, specific SQL error (`ERROR: column "slug" does not exist`), and that raw error text was printed directly into the report, in the exact position where a working section's real results would otherwise have appeared — sitting among nine total sections, the other eight of which ran and reported correctly.

The script's own overall exit code still reported success (0) despite this one section's failure — a design consistent with letting a partial report through rather than aborting the entire run over one broken part, but one that gave no distinct signal, at the script's own top level, that anything inside the report actually required attention. The fix's own account is explicit about the more general lesson this specific incident is used to illustrate: a report or audit output containing even one dead, error-printing block — however it got there — trains whoever reads that report regularly to treat unfamiliar-looking output near the report's edges as ordinary noise rather than as a signal, and the very NEXT time a different section breaks in a similarly unfamiliar way, it will very plausibly be read past for the identical reason. This particular report had already been cited, before the defect was found, as evidence that production access configuration was fully and correctly measured — a claim the broken section could not actually support, regardless of what the other eight sections legitimately proved.

It is worth stating plainly what this defect did NOT put at risk: every other section of the same inventory — the ones reconciling aggregate financial totals and identifying orphaned records with no valid owner — ran correctly the entire time, and the underlying financial data itself was never shown to be, nor found to be, in any doubt. The defect was narrow and specific: one particular section, measuring who currently holds which module-level permission, silently failed to measure anything at all.

The fix itself is a one-line correction to the query's source of truth: rather than joining out to a `modules.slug` column that was never actually present in production, the corrected query reads the module's name directly from the permissions table's own `module` text column, which already stores that name without requiring any join at all. Run against the real database, the corrected section now reports concrete, specific figures — six matching rows, spanning two organizations, across five distinct roles (admin, client, executor, manager, and salesperson) — replacing what had been an unhandled database error with an actual, verifiable answer.

A smaller, specific detail shaped how the fix itself had to be diagnosed and verified: the inventory script carries its own standing safety rule requiring every query it runs to begin with `select` or `with`, specifically because the entire script is meant to be strictly read-only against production. That same guard correctly rejected an earlier, exploratory version of the corrected query that had been temporarily commented out for inspection during debugging — the identical safety mechanism that makes this script trustworthy to run directly against live production data also, correctly, refused to let a malformed draft of its own fix slip through unexamined.

Before the fix, running Centriu Loop's production inventory script produced a nine-section report in which one specific section — meant to enumerate current permissions by organization and role — printed the raw text `ERROR: column "slug" does not exist" instead of an actual answer, while the script's own final exit code still reported overall success. That exact report had already been referenced elsewhere as confirmation that production access configuration was fully measured and correct. After the fix, the identical section instead reports a specific, concrete answer — 6 rows, 2 organizations, 5 distinct roles — measured directly against the real production database, with no error printed anywhere in the report.

Centriu Loop's production access-permissions inventory section now runs successfully against the real database, reporting concrete, specific figures instead of a silently-printed SQL error that had previously gone unnoticed inside an otherwise-successful, exit-0 report — correcting a report that had already been cited elsewhere as proof of full measurement, while confirming the OTHER eight sections of the same report, including financial reconciliation, had been running correctly the entire time.

This automation governs the internal correctness of Centriu Loop's own read-only production-inventory verification script — it does not change any customer-facing feature, does not alter the actual permissions or financial data being measured, and is specific to a script's own single defective query; a monitoring or auditing approach that surfaces a query-level failure as a distinct, non-zero exit condition rather than embedding it inside a still-successful report would not be exposed to this exact class of silent partial failure.

Letting a multi-section report continue past one section's failure, printing that failure's raw error text and moving on, preserves the value of every OTHER section that does succeed — the alternative, aborting an entire report over one broken part, would have hidden the eight working sections along with the one broken one. The gap is specifically in the script's own FINAL exit status: continuing past a failure while still reporting overall success at the end removes the one signal that would have reliably told an automated caller, or a habitual reader skimming for a nonzero exit code, that something inside this specific report still needs a second look.