meshcore-client

History

diffwireauto 6574ecfa90 epic(#939 ): close the stale-read window, and a verdict on #190 Epic D of Feature #853. A different defect class from Epic B: these stores ARE correctly per-radio and bled anyway, through timing. D2, #158: the window was an unexpected disconnect. A manual `disconnect()` clears `_selfPublicKey`; `_handleDisconnection()` did not. So after a drop, every per-radio store, and the one `channels_screen` builds from `selfPublicKeyHex`, still held the previous radio's prefix. Connect a DIFFERENT radio and any read before its SELF_INFO landed served the old radio's history. That matches #158 being seen on desktop and not Android: it is a race, not a logic error. `_clearStorageScopeKeys()` now runs on an unexpected drop. It clears `_selfPublicKey` as well as the eleven connector-owned stores and StorageService, because `channels_screen` does not share those instances and derives its key from the getter, so clearing only the stores would have left that path reading stale. Verified before relying on it: every one of the thirteen per-radio stores guards on an empty key, in BOTH directions. I checked rather than assumed, because if any had used a bare prefix instead, clearing the key would have created a NEW unscoped global key, which is the exact bug class this Feature exists to remove. The names and deviceId stay, so the UI can still say which radio it is reconnecting to; only the data-scoping identity goes. D1, #190: its named root cause is addressed, proven not argued. #190 blamed slot-index keying with no PSK binding. Two mechanisms landed since: PSK-identity keying (#194) and the reuse-clear in `setChannel` (#193). Rather than assert that, there are tests reproducing #190's own scenario, a slot reassigned to a different channel: - keyed by PSK, the newly added channel reads a different key and sees nothing of the old occupant, which is #190's reproduction - the old occupant keeps its own history, because this is isolation by identity rather than deletion - the index fallback still works and still warns, pinning the remaining surface What remains of #190 is the index fallback firing before the channel list has loaded, which is #333 and a timing problem, so it belongs to this Epic rather than to #190. Recommendation for the owner: close #190 as superseded by #193, #194 and this Epic. Not closing it myself; it is his call and D1 was scoped as a verdict with evidence, not a closure. Suite 1,425 pass, analyze clean, format clean. Citadel: meshcore-open-pdx, meshcore-open-cwd Refs #939, #158, #190, #333, #853 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		3 weeks ago
..
connector	epic(#939 ): close the stale-read window, and a verdict on #190	3 weeks ago
helpers	epic(#868 ): companion CLI codec, service, console + entry (F2/E2.1) (#903 )	4 weeks ago
icons	ran dart format . on libs/icons/los_icon.dart	9 months ago
l10n	epic(#938 ): Blocked pane says "no radio" instead of "no blocked users"	3 weeks ago
models	fix(#848 ): scope channel notify modes per radio, kill index fallback	4 weeks ago
screens	epic(#938 ): Blocked pane says "no radio" instead of "no blocked users"	3 weeks ago
services	task(#937 ): B2+B3 path history and delivery observations per radio	3 weeks ago
storage	task(#937 ): B2+B3 path history and delivery observations per radio	3 weeks ago
theme	chore(#457 ): remove em-dash characters from source	4 months ago
utils	fix(#931 ): two defects from the second pre-PR review	3 weeks ago
widgets	fix(#848 ): scope channel notify modes per radio, kill index fallback	4 weeks ago
main.dart	task(#937 ): B2+B3 path history and delivery observations per radio	3 weeks ago