Raised by Codex on PR #152 (fix for #146) and deferred there as an edge case needing a product decision rather than a quick fix within that PR's 3-round review budget.
rememberDevice (v2/mobile/src/lib/savedDevices.ts) only treats an id-less reconnect as ambiguous -- and so refuses to update any existing row -- when two or more id-less saved rows already share the connecting host:port. #146 fixed that multi-row case (and the data-loss-on-migration case).
It did not change the single-match path, which predates #146: when exactly one id-less saved row already sits at an address (the common case, e.g. legacy port 5555) and a different, also id-less, TV takes over that address (DHCP reassignment, a replaced device, etc.), sameTv still matches that lone row by endpoint alone and rememberDevice overwrites its name/type in place, keeping the original row's localId. The new TV's connection is attributed to the old row rather than recognized as a distinct identity.
This is the same address-reuse ambiguity #146 is about, just on the first occurrence instead of the second: the moment a second id-less TV reuses an address, it silently takes over the existing saved entry instead of staying distinct.
Why this wasn't fixed in #146 directly: the only way to keep the two TVs apart here is to stop trusting a lone endpoint match for id-less rows at all, but a lone endpoint match is the established, already-shipped identity heuristic for id-less TVs everywhere else in the app (savedDeviceMatchesConnection, cachedDeviceName, discovery-row "connected" attribution, all predate #146 and are covered by existing tests such as "matches id-less rows only at the exact endpoint"). Naively refusing to update a lone match would also reintroduce the storage-proliferation problem #146's round-1 Codex review flagged (a new row on every ordinary reconnect once nothing is ever "the same" row).
Needs a product decision, e.g.:
- Accept the current behavior (the row just means "whatever id-less TV currently answers at this address", which is already roughly how the rest of the app treats id-less identity), and make that explicit in the UI/docs instead of implying continuity.
- Or add a weaker secondary signal (e.g. a model/name sanity check before silently renaming) and show an honest "this may be a different TV" notice instead of a silent overwrite, similar to the existing
savedHostHasMultipleIdentities messaging.
Files: v2/mobile/src/lib/savedDevices.ts (sameTv, rememberDevice), v2/mobile/src/lib/identity.ts.
Raised by Codex on PR #152 (fix for #146) and deferred there as an edge case needing a product decision rather than a quick fix within that PR's 3-round review budget.
rememberDevice(v2/mobile/src/lib/savedDevices.ts) only treats an id-less reconnect as ambiguous -- and so refuses to update any existing row -- when two or more id-less saved rows already share the connectinghost:port. #146 fixed that multi-row case (and the data-loss-on-migration case).It did not change the single-match path, which predates #146: when exactly one id-less saved row already sits at an address (the common case, e.g. legacy port 5555) and a different, also id-less, TV takes over that address (DHCP reassignment, a replaced device, etc.),
sameTvstill matches that lone row by endpoint alone andrememberDeviceoverwrites its name/type in place, keeping the original row'slocalId. The new TV's connection is attributed to the old row rather than recognized as a distinct identity.This is the same address-reuse ambiguity #146 is about, just on the first occurrence instead of the second: the moment a second id-less TV reuses an address, it silently takes over the existing saved entry instead of staying distinct.
Why this wasn't fixed in #146 directly: the only way to keep the two TVs apart here is to stop trusting a lone endpoint match for id-less rows at all, but a lone endpoint match is the established, already-shipped identity heuristic for id-less TVs everywhere else in the app (
savedDeviceMatchesConnection,cachedDeviceName, discovery-row "connected" attribution, all predate #146 and are covered by existing tests such as "matches id-less rows only at the exact endpoint"). Naively refusing to update a lone match would also reintroduce the storage-proliferation problem #146's round-1 Codex review flagged (a new row on every ordinary reconnect once nothing is ever "the same" row).Needs a product decision, e.g.:
savedHostHasMultipleIdentitiesmessaging.Files:
v2/mobile/src/lib/savedDevices.ts(sameTv,rememberDevice),v2/mobile/src/lib/identity.ts.