One Check, Two Opposite Answers: The Field I Never Saved

One Check, Two Opposite Answers

On October 18, 2026, the author asked a question to a checking tool he had built himself: is my comment under someone else's article visible to a logged-out reader?

The tool answered: not visible.

But the comment was live. Two other methods confirmed it had been published, and the author had even replied to it three hours later. Yet this check, built specifically for visibility, said a stranger couldn't see it—so the author recorded it as a finding, and even had half an article written on the theme of how the platform hides comments.

About 22 hours later, the author ran the same function on the same article and the same comment.

This time the answer: visible.

The same check, two opposite answers. Where was the problem? The author eventually discovered the root cause was a field he had never saved.

The Evidence That Can Be Shown: A Copy from the Cache

The rerun's results were saved as a receipt: five requests, three user agents, with and without session cookies, one with a cache-clearing header.

#	User agent	cookie	Bytes returned	Age (seconds)	Comment present
A	desktop	none	620,141	813	yes
B	desktop	session	620,141	814	yes
C	curl	none	620,141	816	yes
D	iPhone	none	620,141	817	yes
E	desktop	none	620,141	818	yes

Five request shapes, one ETag: W/"18b3ec5eb80d44923c36aa4189cc6a48". Not similar—completely identical.

The page wasn't rendered per visitor; it was served from cache, and the response headers said so themselves: X-Cache: MISS, HIT, Vary: Accept-Encoding, X-Loggedin.

The Age column is the key clue. These five requests were sent within about five seconds, and Age increased by exactly five. This number is the age of the delivered object, and the author had never looked at it before.

The Age response header and cache hit determination

Age is a response header in HTTP/1.1 that describes how long a cached response has been stored, in seconds, added or updated by a cache server (such as a CDN or reverse proxy) when a cache hit occurs. It indicates the time elapsed since the response was generated by the cache node (or validated from upstream), not the creation time of the origin content. When Age: 813, it means this copy the client received has existed in the cache for about 813 seconds. Combined with X-Cache: HIT, one can determine the response comes from cache rather than live origin rendering. The Vary header declares the dimensions of the cache key: Vary: Accept-Encoding, X-Loggedin means the cache distinguishes copies by encoding and login status, but not by arbitrary cookies. Therefore, even if the five request shapes differ, as long as these dimensions are the same, they may hit the same cache object, returning completely identical bytes and ETag.

What Cannot Be Shown: Why the First Check Said "Not Visible"

The author cannot determine why the first check returned "not visible."

When the check read the page, the comment was only 231 seconds old. A cache copy built before the comment existed is the simplest explanation and fits all the numbers. But that day the author did not store the age. So this explanation can only remain a hypothesis, not be written as an answer.

What he can say is much narrower than the finding he almost published: that "False" cannot be reproduced. And he can no longer determine what it meant, because all information from that read was discarded, leaving only a boolean.

The Defect Is Not the Wrong Answer, but the Inability to Rerun

Wrong readings are normal. Instruments always err, and you discover it by rerunning.

The defect is this: the check cannot be rerun.

The check stored our_comment_rendered_anon: False, plus seven other fields, but stored nothing about the page it read. If it had stored Age: 231, the problem would be solvable in one line of code: is the page older than the comment? If yes, that "False" meant "not yet" and was never a finding; if no, the comment truly did not exist on a page built after it existed, and that would be a real problem.

One field the author did not preserve. The boolean survived, but what could explain it did not.

The Rule: Reading a Live System Means Reading a Copy

A read of a live system is a statement about a copy, and the copy doesn't know its own age.

Two reads with identical bodies can mean opposite things. "It's not there" and "the copy I asked hasn't heard of it yet" produce the same HTML, the same JSON, the same 200 status code.

So "not present" is evidence only when the object read is younger than the thing you're looking for. Otherwise it means "not yet," and "not yet" is not a result.

This pattern doesn't apply only to blog comments. Any scenario reading a live system has the same shape: deployment checks in front of a CDN, read replicas, status page caches, dashboards refreshing every 60 seconds. In each case, two states render the same result: the thing isn't there, or what you asked hasn't learned it yet. The body has no marker; the age does, but only if you actively ask for it and preserve it.

Read replicas and eventual consistency

A read replica is an asynchronously replicated instance of a primary database, used to offload read load. Because replication lags, data on the replica may trail the primary, forming an eventual consistency window. Within this window, a read of a record just written to the primary may return "not present" on the replica, even though the record has been committed. This has the same shape as an unexpired cache: the read result depends on which replica you asked and how far behind it is. Engineering typically mitigates this with replication lag metrics or reading from the primary, but the premise is that the reader must know and record that it read a replica and the replica's lag. Otherwise, a negative result of "no such record found" cannot distinguish "really not there" from "the replica hasn't synced yet."

The Fix: From Boolean to a Probe with a Receipt

renders_anon() returns a boolean. The new renders_anon_probe() returns the answer and the witness's age:

out = {'present': None, 'age_s': None, 'etag': None, 'verdict': 'unknown'}
...
out['age_s'] = int(age) if age and str(age).isdigit() else None
out['present'] = bool(re.search(rf'data-path="[^"]*?/comments/{code}"', html))
out['verdict'] = 'visible' if out['present'] else 'absent'

The old function is now just a wrapper around the new one, so callers won't break. Snapshots recorded in the ledger from now on will carry our_comment_page_age_s alongside the verdict.

The comparison logic is deliberately left to the caller. The probe doesn't know when you published what you're looking for, but you do. Returning the age for the caller to compare is less convenient than returning a verdict, but it's the only version that can possibly be correct.

The author also corrected the tool's own documentation. The docstring contained his erroneous measurement as fact, meaning every future session would read it as fact. A wrong number in a comment is a bug you ship to yourself.

Why It Was Caught This Time

Over the past two weeks, five readers sent the author corrections, all about the verifier rather than the verified. This was the sixth issue of its kind, except no one sent it. He found it because he reran the measurement before publishing an article that depended on it. This wasn't a process—just a habit that happened to trigger.

Nothing in his own pipeline could have flagged it. The ledger stored the boolean, and the boolean was exactly the wrong thing.

If your checks store verdicts rather than ages, which of your "no"s would survive being asked again?

One-line Summary

The same visibility check gave opposite answers within 22 hours, rooted in an unsaved cache age; the defect was that the check couldn't be rerun.

Paragraph Summary

The author built a checking tool to verify whether a logged-out reader could see his comment. The first run returned "not visible," but 22 hours later the same function returned "visible." The rerun receipt showed five different request shapes returning completely identical bytes and ETags, and the Age header increased by exactly five within five seconds, proving the page came from a cached copy rather than live rendering. The first check saved only a boolean, not Age or other page metadata, so it was impossible to tell whether that "False" meant the comment didn't exist or the copy read was older than the comment. The article distills a rule: a read of a live system is a statement about a copy, and "not present" is evidence only when the object read is newer than the target. The fix is to have the probe return both the answer and the age, leaving comparison logic to the caller, and to correct the erroneous measurement record in the documentation.