[ryanbr]

Fixes #1527. Reported from a real device: a WHOOP 4.0 syncing every day showed "Last seen 45 d ago" on its Devices card, while the same session's strap log said Last sync: just now and carried History: 37 day rows.

Cause

lastSeenAt was written in exactly four places, none of them a connection — the schema migration that creates the row, the add-device wizard, DataSourcesScreen, and the promote-to-active query. WhoopBleClient makes no registry write at all, so a strap could connect, bond, offload and score for weeks without the column moving. It was reporting time since the row was added.

The fix

Stamped from connectedPeripheralChanged on both platforms — the function that already resolves the connected strap to a registry row, and already refuses to overwrite a row pinned to a different strap. Sitting there means the fix inherits those guards instead of re-deriving identity:

event	behaviour
connect, identity adopted or already matching	stamp
the #52 stale-pin re-adopt (Swift)	stamp — same confirmed strap
a different strap under this row	no stamp — that strap is not this row
disconnect	stamp — the strap was in hand right up to that instant
null republish with no prior link	nothing — not a sighting

The disconnect edge earns its place: stamping only on connect would leave an overnight session reading "Last seen 10 h ago" the moment the link dropped, which is a subtler version of the same lie.

Once per connect and once per disconnect, not per packet — a write per second would buy no more truth. Archived rows are excluded in the SQL on both sides, since "Removed · data kept" is a deliberate resting state and a stray connect must not resurrect one into looking live.

Scoped to the WHOOP path, which is what was reported. The other source kinds have their own connect paths and are untouched.

Verification

• 6 new tests in SourceCoordinatorAdoptionTest — both edges, the different-strap guard, the bare-null case, and the archived guard. Confirmed they actually ran (the class goes 10 → 16) rather than the filter matching nothing.
• Full Android suite: 4,195 tests, 0 failures (--no-build-cache --rerun-tasks; 4,189 on main, +6).
• app-build 32528687310 green on both legs, including Test Strand — so the app-target Swift compiles and StrandTests passes. Default CI covers neither.
• Doc lint and i18n audit clean.

Worth flagging

Writing this I inserted all three new declarations between an existing doc block and its declaration. Kotlin's /** */ blocks stack visibly and the doc lint caught two of them — but the Swift one merged silently, because consecutive /// lines join into one block: connectedPeripheralChanged lost its entire doc comment into my helper's, and the lint did not flag it. All three are moved above their neighbours now, and I checked each doc is reattached to the declaration it describes. The Swift blind spot is worth remembering; it fails quietly.

Not fixed here, from the same report: the green Active badge is the registry status, not a live connection, so "Active" next to a stale last-seen reads as a contradiction. Fixing the timestamp removes most of the sting. The charging disconnect that prompted all this is #1528, awaiting a log.

[ryanbr]

Re-reviewed my own branch and found a real defect in it, fixed in 2d2c1a6-range (see the new commit).

The bug

The disconnect edge stamped activeDeviceId, and my doc comment claimed the isWhoop guard stopped a strap switch from stamping the wrong row. It doesn't. isWhoop only checks that the active row is a WHOOP — so on a multi-WHOOP install, strap A drops while B is active, and B is recorded as seen despite never having been connected.

That is precisely the mis-mapping the peripheralId guard three lines below exists to prevent. I wrote a guard, described it as doing something it didn't do, and the description read plausibly enough that I nearly shipped it.

The fix

The disconnect now resolves the row by the identity the strap adopted — the address it was connected on — via the existing deviceForPeripheralId / device(forPeripheralId:). An address no row has adopted stamps nothing rather than guessing at the active row.

Simpler as well as more correct: the identity lookup subsumes the isWhoop check, because only a WHOOP row can have adopted a WHOOP peripheral id.

Verification of the tests themselves

Two new tests, and I checked they are worth having by reverting the helper to the old implementation and confirming both fail:

com.noop.ble.SourceCoordinatorAdoptionTest > aDisconnectFromAnUnadoptedStrapStampsNothing FAILED
com.noop.ble.SourceCoordinatorAdoptionTest > theDisconnectStampsTheStrapThatWasConnectedNotWhateverIsActiveNow FAILED
tests="18" failures="2"

then restoring and confirming 18/0. A regression test that passes against the bug it names is worse than none.

• Full Android suite: 4,197 tests, 0 failures (--no-build-cache --rerun-tasks).
• app-build 32530048388 green on both legs, Test Strand included.
• Doc lint and i18n clean.

Also worth recording: an intermediate --tests-filtered run reported BUILD SUCCESSFUL with everything UP-TO-DATE while leaving the previous run's result XML in place — 16 tests, 0 failures, none of them mine. Reading that as a pass would have been wrong twice over. --rerun-tasks is what makes the filtered runs honest.

[ryanbr]

Second re-review pass — one more real defect, Android-only.

Matching identity two different ways

The connect path treats an address differing only in case as the same strap:

existing.equals(address, ignoreCase = true)

That reads as deliberate — someone saw MAC-case variance. But my disconnect resolved the row through deviceForPeripheralId, whose WHERE peripheralId = ? is case-sensitive in SQLite. So a case-different address would adopt and stamp on connect, then silently stamp nothing on disconnect — the exact quiet staleness this branch exists to remove, reintroduced by being stricter on one edge than the other.

Now matched to the adjacent guard rather than the shared query, which other callers use and which the Swift store mirrors exactly.

Deliberately not changed on Swift. Its connect path compares exactly (case .some(uuid)), so its exact lookup already agrees with its own adopt rule. Each side matches ITS OWN rule; making the two helpers identical would break one of them. The platforms already differ here and that difference predates this branch.

Checked and clean

• The Swift publisher is .removeDuplicates() before the sink (SourceCoordinator.swift:144), so a republish of the same uuid cannot stamp repeatedly. That was the other thing I wanted to rule out.

Verification

One new test, again verified to fail against the previous lookup:

aDisconnectResolvesTheStrapCaseInsensitivelyLikeTheAdoptGuard FAILED   (tests="19" failures="1")

then passing at 19/0 after the fix. Full Android suite 4,198 tests, 0 failures, doc lint and i18n clean.

No new app-build for this one: the commit touches only android/, so 32530048388 still covers the Apple half — I checked git diff --stat against Strand/ and Packages/ rather than assuming.