From eccd28ea0d4f1dfa3d05b01194c531f3bbad22b0 Mon Sep 17 00:00:00 2001 From: serversdown Date: Fri, 25 Sep 2026 13:11:18 -0400 Subject: [PATCH] docs(series4): "not polling" and "unreachable" are different states Follow-up to the reproduced wedge, and the sharpest point to come out of it -- the operator's observation, demonstrated directly. At 13:10:44, six and a half minutes after THOR's last connection of any kind: THOR connections since 13:04:22 : 0 independent POLL through the same relay, same moment : succeeds The unit is reachable. The link is fine. THOR is simply not asking. So whatever THOR's UI reports in that window is wrong. "Connected/OK" is false because nothing has been checked for minutes. "Disconnected/unreachable" is also false because the unit answers on demand. The true state -- "I have given up checking this unit" -- is not one THOR can display. An operator therefore cannot separate "the unit is down" from "the poller is asleep", and those demand completely different responses: a site visit versus a mouse click. This settles a question the previous commit left open. It does not matter much whether stopping after one retry is intentional or a defect: the reporting is wrong either way, since both plausible displays misrepresent reality. Sharpens design consequence 4 accordingly -- a unit's displayed state should be one of: checks passing, checks failing (with attempt count and last error), or not being checked (with why, and a way to resume). Collapsing the last two into a single indicator is the root of this failure being undiagnosable. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 44 ++++++++++++++++++++++++---- 1 file changed, 38 insertions(+), 6 deletions(-) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index f058996..9aaf771 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -1811,10 +1811,38 @@ while nothing is actually watching it. The operator sees a successful check and moves on; the background loop stays dead. That is worse than a refresh button that plainly fails, because the failure is *silent and looks like success*. -It also explains why the field symptom is hard to characterise: the unit is -perfectly reachable the whole time. Poke it and it answers. Nothing is wrong -with the unit, the modem, or the link — THOR has simply stopped asking, and says -nothing about it. +### 🔑 "Not polling" and "unreachable" are different states — and THOR conflates them + +Demonstrated directly. At **13:10:44**, six and a half minutes after THOR's last +connection of any kind: + +``` +THOR connections since 13:04:22 : 0 +independent POLL through the same relay, same moment : succeeds, correct response +``` + +**The unit is reachable. The link is fine. THOR is simply not asking.** + +Whatever THOR's UI reports in that window, it is wrong: + +| if it shows | why it is false | +|---|---| +| connected / OK | nothing has been checked for minutes | +| disconnected / unreachable | it **is** reachable — THOR stopped trying | + +The true state is *"I have given up checking this unit"*, and no display in THOR +expresses it. So an operator cannot separate **the unit is down** from **the +poller is asleep** — and those demand completely different responses: a site +visit versus a mouse click. + +This also settles a question the previous section left open. It does not much +matter whether stopping after one retry is an intentional design choice or a +defect: **the reporting is wrong either way**, because both plausible displays +misrepresent reality. + +It explains, too, why the field symptom resisted characterisation. The unit is +perfectly reachable throughout. Poke it and it answers. Nothing is wrong with +the unit, the modem, or the link. ### Design consequences for SFM @@ -1826,8 +1854,12 @@ nothing about it. 3. **Surface the poll loop's own state** — last successful check, last attempt, next scheduled attempt, consecutive failures. All four were invisible here, and every one of them would have made this diagnosable in seconds. -4. **Distinguish "unit unreachable" from "we stopped checking."** They present - identically in THOR and have completely different causes and fixes. +4. **Distinguish "unit unreachable" from "we stopped checking."** Proven above + to be different states that THOR cannot tell apart. A unit's displayed state + should be one of: *checks passing*, *checks failing* (with the attempt count + and last error), or *not being checked* (with why, and a way to resume). + Collapsing the last two into one indicator is the root of this whole failure + being undiagnosable. ### Caveats