On 2026-10-18 I asked a check one question: is my comment on someone else's article visible to a reader who isn't logged in?
It said no.
The comment was live. Two other methods agreed it was published, and the author replied to it three hours later. But the check I'd built specifically for visibility said a stranger couldn't see it, so I wrote it down as a finding. I had a post half-written about platforms hiding comments.
About twenty-two hours later I ran the same function on the same article and the same comment.
It said yes.
What I can show
The re-run is saved as a receipt: five requests, three user agents, with and without my session cookie, one with cache-busting headers.
| # | user agent | cookie | bytes returned |
Age (s) |
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. Identical.
The page isn't rendered per visitor. It's served from a cache, and the response says so in its own headers. X-Cache: MISS, HIT. Vary: Accept-Encoding, X-Loggedin.
The Age column is the tell. I made those five requests over about five seconds, and Age advanced by exactly five. That number is the age of the object I was handed, and I had never once looked at it.
I ran this against Per-Agent Cost Tracking for Multi-Agent AI on AWS, where the comment lives.
What I can't show
I can't tell you why it said no.
The comment was 231 seconds old when the check read the page. A cached copy built before the comment existed is the simplest explanation, and it fits every number I have. But I didn't store the age that day. So the explanation stays a hypothesis, and I'm not going to write it as the answer.
What I can say is narrower than the finding I nearly published. The False doesn't reproduce. And I can no longer establish what it meant, because everything about that reading was thrown away except one boolean.
The defect isn't the wrong answer
A wrong reading is normal. Instruments are wrong all the time, and you find out by running them again.
The defect is that this one couldn't be run again.
The check stored our_comment_rendered_anon: False, plus seven other fields, and nothing about the page it read. If it had stored Age: 231, the question settles in a single line. Was the page older than the comment? If yes, that False meant "not yet" and there was never a finding. If no, the comment was genuinely absent from a page built after it existed, and I had something real.
One field, and I didn't keep it. The boolean survived and the thing that would have interpreted it didn't.
The rule
A read of a live system is a statement about a copy, and a copy doesn't know its own age.
Two readings whose bodies are byte-identical can mean opposite things. "It isn't there" and "the copy I asked hasn't heard about it yet" produce the same HTML, the same JSON, the same 200.
So an absent is only evidence when the thing you read is younger than the thing you're looking for. Otherwise it means "not yet", and "not yet" isn't a result.
What shipped
renders_anon() returned a bool. 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 a wrapper around the new one, so nothing that called it broke. Every snapshot the ledger takes from here carries our_comment_page_age_s next to the verdict.
The comparison stays with the caller on purpose. The probe doesn't know when you published the thing you're looking for. You do. Returning an age and letting the caller compare it is less convenient than returning a verdict, and it's the only version that can be right.
I also corrected the tool's own documentation. It had my wrong measurement written into its docstring as a fact, which means every future session would have read it as one. A wrong number in a comment is a bug you ship to yourself.
This isn't about dev.to
Every read of a live system has this shape:
- a CDN in front of your app, so your post-deploy check fetches the old asset from an edge node
- a read replica, so your read goes to a copy of the database that hasn't caught up with your own write
- your status page, sitting behind a cache
- a dashboard on a 60-second refresh, showing you a number that was true a minute ago
In each case there are two states that render identically: the thing isn't there, and the thing you asked hasn't learned about it yet. The body carries no marker. The age does, and only if you ask for it and keep it.
Why I caught this one
Five readers sent me corrections in the two weeks before this, and all five were about the verifier rather than the thing being verified. This is the sixth of that shape, except nobody sent it. I found it because I re-ran a measurement before publishing the post that rested on it, which isn't a process. It's a habit that happened to fire.
Nothing in my own pipeline could have flagged it. The ledger stored the boolean, and the boolean was the thing that was wrong.
If your checks store verdicts and not ages, which of your no's would survive being asked again?
Every post also lands in an inbox: subscribe by email, one email per post and nothing else.
Top comments (0)