There's a particular kind of silence in a codebase. Not the silence of nothing happening — the silence of something you believe is standing guard, and isn't.

I help maintain a trading-strategies codebase: Ruby, grid ladders, limit orders placed on a venue through an API gateway. Inside its order-retry loop there was a thoughtful little branch for rate limits. If the venue rejected an order because you were sending too fast, the code would parse the "blocked for N seconds" out of the error message, sleep exactly N seconds, and try again. Considerate. Correct-looking. Reviewed, merged, shipped.

when 'other'
  if order['venueErrorMessage'] =~ /blocked for ([0-9]+)/
    # ...compute the wait, log it, sleep it...
  end

One problem. The field is called venueMessage. venueErrorMessage does not exist — not in the response, not anywhere in the gateway's API schema. And Ruby, bless it, does not care. Hash access on a missing key returns nil. nil =~ regex is just nil. No exception, no warning, no log line. The condition evaluated false on every rejection the code ever handled, and the interpreter's official position was that this was fine.

So the branch never ran. Not once, as far as anyone can reconstruct — dead code from the day it was written. Every order that flowed past it took the other path, and nothing anywhere recorded that a path even existed.

Dead Code Doesn't Fail

Here's what makes this failure mode nasty: it wasn't caught by failing. It couldn't fail. Code that never executes throws no exceptions, corrupts no state, trips no alerts. It just sits there in the diff looking responsible, collecting review approvals, while the behavior it promises quietly doesn't exist.

It surfaced only because two other bugs went off on a live run against Kraken BTC/USD.

Bug one: the strategy rounded order prices to the quote currency's display precision — two decimals, because USD. Kraken's BTC/USD pair only accepts limit prices to one decimal. An ASK rung went out at 63409.19 and bounced: EOrder:Invalid price:BTC/USD price can only be specified up to 1 decimals.

Bug two: the retry loop treated that permanent rejection as retryable, and resubmitted the identical invalid price forever — exponential backoff, no attempt cap, no permanent-versus-transient classification. Initialization wedged on one bad rung; seventeen remaining rungs were never placed.

Root-causing bug two meant answering a question: which field in the rejection actually tells you whether it's worth retrying? That meant reading the API schema — the actual authoritative document — instead of the code's beliefs about it. The schema said: the venue's explanation lives in venueMessage. And the code said venueErrorMessage. That's the moment the corpse was found: not because the branch misbehaved, but because a neighboring bug forced someone to check the code's claims against the source of truth, and one of the claims turned out to be about a field that had never existed.

The Sibling: Luck as a Test Harness

Bug one carries its own uncomfortable lesson. That wrong rounding basis — two decimals instead of one — had been live in the strategy's static mode without a single rejection. Why? Because static ladders happened to place rungs at the ticker price plus or minus integer increments. Start at one decimal, add whole numbers, and you stay at one decimal forever. The arithmetic never manufactured a second decimal place, so the venue never saw an invalid price, so the wrong code looked right.

Then a new auto-adjust mode computed rung spacing as window-span divided by rung count — full-precision floats — and the venue rejected the second order it ever saw.

Two bugs, same shape. One protected by a language that turns typos into nil, one protected by inputs that were accidentally clean. Neither had ever failed, and in both cases, absence of failure was the entire body of evidence for correctness. Which is worth saying plainly: absence of failure is not evidence of correctness. It is evidence of absence of failure — a description that also fits, perfectly, code that never runs at all.

Field Names Are Claims

When I write order['venueErrorMessage'], it doesn't feel like a claim. It feels like plumbing. But it is a claim — an assertion about a remote system's contract, stated with the syntax of certainty and verified by absolutely nobody. There's no compiler to check it. The interpreter won't check it; nil is an answer, not an error. And the test suite didn't check it, because the test fixtures were written from the same assumption as the code — they faithfully stubbed 'venueErrorMessage' => nil into every mock order. We tested our own typo against itself, and it passed.

The only authority on what a remote API returns is the API's actual specification, and nothing in the toolchain consults it on your behalf. Every field name in the codebase is testimony. Testimony can be checked against the source, or it can be believed — and the cost of believing it is invisible right up until something forces the audit.

The Fix, For the Record

The fix shipped the same day the live run failed: read venueMessage, the field that exists; check failureType == 'rate_limit_exceeded' as the primary rate-limit signal instead of regex-matching prose; cap retries at a named constant; classify validation-class rejections as permanent and skip the rung with a warning instead of wedging the whole set; require the venue's price precision as explicit config that fails closed if missing; and round bids down, asks up — away from the market, so coarser precision can only ever make an order more conservative.

Deployed, then verified against the live venue: eleven of eleven ASK rungs at one decimal, zero rejections. And a rate-limit branch that can — for the first time in its life — actually execute.

The Branch Is Still There

I keep the old diff around as a memento, mentally at least: a perfect artifact of code that was written, reviewed, approved, merged, and never once observed doing its job. Every instrument green. Every checkbox honest. The tests passed over it, the reviews approved around it, and the one question that mattered — does the field this branch reads exist? — was never in anyone's checklist, because the code compiled and code that compiles feels checked.

Code that cannot fail is not the same as code that cannot be wrong. Sometimes it's the opposite: the wrongness is exactly what's keeping it from ever running far enough to fail. The silent ones don't announce themselves. You find them the way we found this one — by verifying a claim you had no particular reason to doubt, and pulling on the thread.

Check the field names. The schema knows things your codebase only believes.