The Zero That Wasn't Zero

Someone on the team noticed a transmittal on the Liquidation Tracker sidebar showing a total of zero. Not "zero because there's nothing on it" — zero on a transmittal that clearly had six or eight items sitting inside it. That's the kind of bug that looks small until you start pulling the thread, and this one pulled all the way from a single missing SQL join to a stale React closure that had been quietly lying to the dashboard the whole time.

I've spent twenty-plus years around broadcast signal chains, and the thing that never stops being true — whether it's a router take or a Postgres query — is that a silent failure is worse than a loud one. A dropped frame that freezes the picture gets a phone call in ten seconds. A dropped frame that just... doesn't update, and nobody notices for a week? That's the one that costs you.

The zero-total bug

The transmittals list computes its total by summing the amount from whatever's attached to each line item — a recurring bill, an invoice, a cash advance, or a reimbursement CRF. The query did this with a LEFT JOIN LATERAL that unions together the possible sources:

bill amount, or invoice amount, or CRF total — whichever one actually exists for that row.

Except the union only had three branches. Cash advances and plain reimbursements weren't in it. So any transmittal built out of cash-advance items had nothing to sum — SUM() over an empty set returns NULL, and the query wrapped that in COALESCE(..., 0) "for safety." Which is exactly the problem: that safety net turned a real bug into a plausible-looking zero instead of an error anyone would notice.

I added the missing branches, rebuilt, restarted the API — and the entire transmittals list vanished. Not wrong totals. No rows at all.

Making it worse before making it better

Here's the part I'll own: I'd grepped the codebase for how a sibling method referenced reimbursement_id on the transmittal-items table, assumed that column existed because the code referenced it, and wired my fix around it. It didn't exist. That sibling method was itself already broken — quietly, the same way the zero-total was quiet — and I'd just inherited its mistake instead of catching it.

The fix for that fix was to actually check the table, not the code that assumes things about the table. A quick script against the live database (careful never to print the password, just the query results) showed the real column list: bill, invoice, cash advance, reimbursement CRF. No plain reimbursement column at all. Pulled that branch back out, kept the cash-advance one, rebuilt, verified the query directly against the database before touching the live service again. Fifteen transmittals, real totals, no surprises.

The lesson that's stuck with me from both broadcast and software: verify against the actual signal, not against what the last engineer assumed the signal was doing.

From one bug to "show me who's slow"

That same conversation turned into a bigger ask: a real "what needs my attention" summary across every module — bills, invoices, cash advances, liquidations — and a cycle-time view that shows who's approving fast and who's sitting on things. The kind of dashboard a finance lead actually wants: not just "12 pending," but twelve pending and here's whose desk they're on.

Digging into the existing summary endpoint turned up another one of these quiet failures: the invoices "ready for payment" counter was filtering on a status value — READY_FOR_PAYMENT — that had never actually existed in the database's status enum. It was always going to return zero. Nobody had noticed because zero looks exactly like "nothing pending" until you know to be suspicious of it.

Then, while wiring up the new pending-approvals fetch, I found a bug that would have quietly broken the whole feature I was about to add: the dashboard's data-loading effect checked a "can this user approve things" flag, but that flag was captured from the very first render — before the user's role had even loaded from the server. It always evaluated false. The approvals fetch was never actually running for anyone, for any role. It just happened to not matter yet, because nothing depended on it hard enough for someone to notice.

Line graphs, the boring way

For the "who's performing" chart, I didn't reach for a charting library. The dashboard doesn't have one installed, and the existing cycle-time page already renders its own bar chart with plain CSS. So the new line chart is the same philosophy: an inline SVG component, one polyline per approver, gaps left as gaps instead of interpolated lies, a legend row underneath. Nothing fancy — just enough to answer "who is this," "how many did they approve," and "is that number going up or down month over month."

None of this was one clean pass. It was: notice a wrong zero, fix it, discover the fix broke something worse, verify against ground truth, fix that properly, and only then get to the feature that was actually asked for. Which is, more often than I'd like, just what debugging is — in a control room or in a codebase.