jaraco / jaraco/pluslife-analyzer
Don't pre-select a kit on the "already running test" screen — it decides result interpretation
- Dominant language
- JavaScript
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
`restoreTestType()` re-applies the remembered kit whenever the kit buttons are on
screen and nothing is selected yet. Those buttons appear on **two** screens, and on
the second one the choice means something different.
## The screen in question
When the app connects to a dock that is already running a test
(`BLOCKED_ALREADY_TESTING`, test state 4), it renders the same featured-kit buttons
under the heading *"Select test kit which the test was originally started with"*,
with this warning:
> the test config is only sent to the device when the test is started. When you
> press the button on the device rather than starting the test through the app, it
> defaults to SARS-CoV-2. Even if you select a different test kit here, the device
> will continue to run — and interpret results according to — what it was originally
> started with. Select the same test kit the test was originally started with, or
> displaying the test results won't work correctly.
So on this screen the selection does not configure anything; it tells the app how to
*interpret* results that are already being produced. Getting it wrong mislabels the
run.
## The hazard
We pre-select the remembered kit there, before the user has looked at the screen.
Observed on 2026-08-23: the app reconnected to a running test and logged
`restored kit: SARS-CoV-2` with the button already highlighted by the time the
screen was seen.
It was correct that time, because that test had been started from the app with the
same kit. It would not be correct when the remembered kit and the running test
disagree — most plausibly when the test was started **from the button on the dock**,
which always defaults to SARS-CoV-2 no matter what the app last used. A user whose
last run was Strep A would be shown Strep A pre-selected for a SARS-CoV-2 run, on
the one screen whose entire purpose is asking them to get that right.
## Fix
Gate the restore on the pre-test selection screen only — test state 1 (IDLE) — and
leave state 4 alone:
```js
function restoreTestType() {
if (testState() !== 1) return; // only the pre-test screen; state 4 asks a
... // different question (see #9-era notes)
}
```
`testState()` already exists (it reads `.data.state`). The persist half
should be gated the same way, so a state-4 screen never overwrites `lastTestName`
either.
Worth confirming on hardware afterwards: start a run from the dock's own button with
a different kit remembered, then connect, and check that nothing is pre-selected.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at restoreTestType() and the existing testState() helper, which reads .data.state. Verify both restoring the remembered kit and persisting lastTestName are limited to state 1, while state 4 leaves the selection empty. Confirm on hardware by starting a dock-button run with a different kit remembered, reconnecting, and checking that no kit is pre-selected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 84/100