Build1 distinct publisher2 min readPublished
Suppressing a repeat log line quietly rewrites what the line asserts, and the rewrite only becomes visible after the first invocation, which is the only invocation most tests ever perform.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The predicate never mentions the phone. `[ ! -f "$OFFLINEFILE" ]` asks whether a file exists, and the echo fires only when it does not [2]. After the touch, that branch is unreachable for as long as the condition lasts, so the notice is true once per transition and false on every run afterwards, and the file's mtime becomes the only surviving record of when it was true [3]. The claim that reaches the log is past tense: the phone became unreachable at some earlier point, at least once [4].
Both readings of that code agree on the first invocation, and one invocation is all the history a test has [5]. The author pulled the pre-fix script out of git and ran it in a scratch path to check the behaviour directly [15], rather than trusting the commit that fixed it [13].
Read charitably, the guard exists so nobody gets the same line every five minutes [14]. Thirty-six days at twelve invocations an hour is 10,368 runs [16]. One of them emitted anything, a single 39-byte line, so the suppression's yield over that window was the 10,367 lines it never wrote [17]. The current version emits 91 bytes per run [7], which over the same window comes to 943,488 bytes, about 921 KiB [18].
The channel defect is independent of the tense defect, and the author counts them as two bugs [8]. On the one run that spoke, the message went to stderr, while callers read the tool with command substitution and capture stdout [9]. Exit code 2 came back on every run, before and after the fix [20], so the machine-readable channel was accurate the whole month. It helps only a caller that looks at it.
That is also the condition for any of this to transfer. If your alerting reads exit status, a sentinel guard costs you one log line and no visibility. If your consumers interpolate a captured string into something a human reads, the same guard turns an outage into a blank cell, and a blank cell has no tense to inspect.
The portable part is the author's rule rather than his script: an honest n/a is a claim about the node, not the absence of one [11]. Everything behind it is one machine and one author's own measurements, taken while writing rather than quoted from the repair, and he reports that two of the things he expected to find turned out false [13].
Ranked by verification strength, evidence, and original report placement.
A sensor on the author's machine returned empty stdout, empty stderr and exit code 2 on every invocation for 36 days; it had not crashed and was not misconfigured.
The guard reads: if [ ! -f "$OFFLINEFILE" ]; then echo "body context n/a ... phone unreachable" >&2; touch "$OFFLINEFILE"; fi; exit 2. The echo goes to stderr and the sentinel is touched in the same branch.
Read as a rate limiter, the guard's stated purpose is to avoid spamming the log with the same message every five minutes.
The guard does not limit a rate; because it tests the sentinel's absence, the notice is true exactly once per transition and false forever after, and the sentinel's own mtime is the only surviving record of when the sentence was last true.
Wrapping the present-tense claim "phone unreachable" in the sentinel test rewrites it into the past tense: the phone became unreachable at some earlier point, at least once.
The two propositions coincide on the first run, so a first-time-only notice is indistinguishable from a live one for the length of one invocation, which is exactly the length of the test written for it.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 28, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Your .ai viewer is a pdf.js problem, and its worst bugs never throw1 distinct publisher
build
Seven of sixteen: what a 60-second tick does to an outage record1 distinct publisher
build
Five coding agents on one repo is a staffing problem, and worktrees only fix the filesystem1 distinct publisher
build
MCP's empty-string cursor: the null check that hides most of a tool catalog1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Argument you can recheck, measurements you cannot
The core finding doesn't ask for trust: the guard is quoted in full, and the tense change follows from reading it. Everything around it rests on one person's terminal — byte counts, exit codes, the pre-fix script pulled back out of git and run twice. The author strengthens that by showing the commands and weakens his own headline number himself: the 36 days came from a file timestamp the fix overwrote, and now lives only in a commit message.
Two tools, one laptop
The whole footprint is one personal sensor mesh. The fix is genuinely deployed — the tool prints its verdict on every run and the sentinel now carries the fix's timestamp — and one sibling tool has used the same explicit-n/a phrasing for months. Beyond that machine there is nothing: no library, no other codebase, no downstream user reporting the pattern.
Sold short of the finding
Unusual direction for a debugging post: the framing is smaller than the lesson. "Log this once" guards, diagnostics on stderr and empty-string captures are ordinary furniture in shell tooling, yet the author keeps the claim to one script, publishes the runs that contradicted what he expected to find, notes the exit status was correct the entire time, and declines to reconstruct a timeline he can no longer measure.
Reputation is the only stake
Nothing is being sold and nobody is being blamed: no vendor, employer or product appears, and the code is the author's own. The one pull worth naming is narrative — a mute sensor reads better the worse it sounds — and the retained exit-code-2 finding plus the re-run transcripts push against exactly that.
One machine, one witness, checkable core
A single author reporting on a single machine caps how far this can be taken as an incident report, and no second publisher has looked at it. What keeps confidence respectable is the split: the part that matters most is a code reading anyone can redo, and the parts nobody can redo are the ones the author flags as unrecoverable.