#103 probe: stop reporting silence, and one verb's refusal, as a verdict about the firmware

[vishk23]

Follow-up to #103. The device-config read probe's no-answer verdict printed a single sentence —

neither GET_FF_VALUE(128) nor GET_DEVICE_CONFIG_VALUE(121) is served by this firmware

— for three runs that establish three different things, and for one that establishes the opposite. That sentence is the probe's headline: it is what gets pasted into an issue when someone runs the probe and nothing comes back, so it is the one string that most needs to be true.

The three over-claims

1. Two timeouts asserted a firmware behaviour. BLEManager.send can return without transmitting at all — there is an early return when cmdCharacteristic is missing, and another in the 5/MG allowlist else-branch. A run in which nothing ever reached the strap still rendered a claim about what the strap's firmware serves. The file's own header names answered / rejected as UNSUPPORTED / silent as three distinct outcomes, and then the verdict collapsed silence into the same factual claim as a refusal.

2. The || generalised one refusal to both verbs. 128 answering UNSUPPORTED(3) while 121 times out printed "neither … is served by this firmware — rejected as UNSUPPORTED". 121 was never refused; it was never heard from.

3. .undecodable fell through to the bare "is not served" sentence. A CRC or envelope failure is affirmative evidence the strap did transmit — the opposite of what that sentence says.

The fix

The sentence is now per-verb and tied to the evidence that produced it:

status	wording
unsupported	refused by firmware (UNSUPPORTED)
silent	served no reply in Ns — unconfirmed
undecodable	replied but the frame did not decode — unconfirmed
untried	not asked

noteTimeout now records the reply window rather than only tracing it, so the verdict can name how long nothing came back for instead of converting that silence into a claim about firmware.

Only UNSUPPORTED is the firmware answering, so the strong "not served by this firmware" wording survives in exactly one case — the firmware refused both verbs itself, where the || is now an &&. That run keeps its original string verbatim.

Before / after, for the one-refusal-plus-one-timeout run:

- neither GET_FF_VALUE(128) nor GET_DEVICE_CONFIG_VALUE(121) is served by this firmware — rejected as UNSUPPORTED
+ no read verb answered — GET_FF_VALUE(128) refused by firmware (UNSUPPORTED); GET_DEVICE_CONFIG_VALUE(121) served no reply in 8s — unconfirmed

Scope

Verdict wording only. No change to the wire, the plan, the read-only allowlist, the parse path, or any status transition — setStatus's "a verdict already reached is not upgraded away" rule is untouched. The cross-platform golden report test is unaffected because it exercises the answered path.

Mirrored byte-for-byte in com.noop.protocol.DeviceConfigReadProbe, per the parity contract; the Kotlin twin tests assert the same literals.

Same defect class as the ECG probe fix on #896 — a verdict asserting a conclusion the run's own inputs could not support. Different file, same failure mode: reading the absence of a reply as evidence for the hypothesis the code was written to print.

Verification

• cd Packages/WhoopProtocol && swift test — 428 tests, 0 failures
• cd android && ./gradlew testFullDebugUnitTest — 3199 tests, 0 failures, 5 skipped, confirmed by parsing android/app/build/test-results/testFullDebugUnitTest/*.xml (391 files) rather than trusting the exit code

Four tests carry the fix: the two-timeout case now pins the per-verb sentence and asserts served by this firmware and UNSUPPORTED are both absent; new tests cover one-refusal-plus-one-timeout, two undecodable replies, and a probe that asked nothing. Kotlin twins for each. No hardware run — this is pure string logic over synthetic report state, and every branch is reachable from unit tests.

[ryanbr]

Checked the premise rather than taking it, and it holds on both counts.

BLEManager.send really can return without transmitting — guard state.connected, let p = peripheral, p.state == .connected, let ch = cmdCharacteristic else at :1471, plus the 5/MG allowlist else-branch. So a timeout genuinely is not evidence a frame reached the strap, and a verdict built on it was speaking for firmware that may never have been asked.

And the file's own header at :26 already named answered / rejected as UNSUPPORTED / silent as three outcomes, while the verdict collapsed two of them into one sentence. The model was right and the string did not follow it — which is the most persuasive form this argument can take, because it is the file disagreeing with itself rather than a new opinion.

The || → && is the heart of it and it is correct: "not served by this firmware" is a claim about firmware, so it survives only where the firmware itself refused both verbs. Everything else reports per verb against the evidence that verb produced.

Verified

• Parity is real, not asserted. I diffed the added user-visible literals between the Swift and Kotlin halves — not asked, refused by firmware (UNSUPPORTED), replied but the frame did not decode — unconfirmed, served no reply, no read verb answered, and the both-refused sentence — and they match with zero mismatches. Worth doing because a wording change mirrored by hand is exactly where the two platforms drift apart silently.
• silenceWindow degrades gracefully: a missing window falls back to served no reply — unconfirmed rather than printing an empty duration.
• Adding undecodable to the header's list is the right call, and the reasoning — a frame that failed to decode is affirmative evidence the strap transmitted, the opposite of "not served" — is the sharpest line in the change.
• Verification method noted: parsing the 391 JUnit XML files rather than trusting the exit code is the right instinct, and it is the same reason this repo's Android suite went unchecked for weeks.

The failing check is mine, not yours

check is red on the i18n gate for AppChangelog.kt:42, a hardcoded What's New title — a line this PR does not touch. Cutting 9.2.1 added it: appchangelog-gen.py writes the Android title as a raw Kotlin literal, which is #878, closed but never actually fixed. Fixed on main in #916 and #878 is reopened for the generator.

Two things made it land on your PR rather than being caught at the source: the release workflow pushes with GITHUB_TOKEN, so GitHub ran no workflow at all on the release commits, and the audit is a whole-tree gate rather than a diff, so it fails every open PR on a line none of them touched. Merge main and it clears — nothing to change here.

One observation, not a request

undecodable and silent both end in unconfirmed, while the header now argues they are opposites in what they establish about transmission. The sentences do carry the distinction, so a reader gets it; it is only the one-word tag that flattens it. Fine as is — noting it in case a later reader tries to count "unconfirmed" verbs and finds two different things under one label.

Good change. Green once it picks up main.