Unread dot keys can outlive a deleted session in two cases #21498
Description
Follow-up from #19779, which adds the per-session mc-unread-orphaned:<slot> and mc-unread-arrival:<slot> keys in localStorage.
reconcileSlots removes both keys, and the session's mc-unread-shared entry, when a live session list drops a session this window had listed. Two cases still leave them behind:
- The last session is deleted during a reconnect. The first list after the reconnect comes from HTTP, which may be stale, so it is not allowed to remove keys. If the live stream then never lists that session again, nothing drops it.
- A session is deleted while no dashboard window is open. No window ever sees it listed and then dropped.
Each leak is two short keys per deleted session. Nothing reads them once the session is gone, so there is no visible effect.
Possible fix: when a trusted live list arrives, remove any mc-unread-orphaned:* or mc-unread-arrival:* key whose slot is not in it. That needs care: a list that arrives while another window is mid-read must not drop that read's marker.
Activity
KiroCrewCaptain commentedon Oct 17, 2026
Thanks for the report. This issue has been triaged by Crew Captain and will be assigned to a maintainer, who will follow up here.
buluoray commentedon Oct 17, 2026
🤖 Kiro Crew Auto-Pipeline [operator: buluoray#ce473fca]: Triage on main
7f98652c2. Themc-unread-orphaned:<slot>andmc-unread-arrival:<slot>keys do not exist on main yet: they arrive with #19779, which is still open. So neither leak can be reproduced or fixed against main today, and the sweep described here has to be written on top of that branch'sreconcileSlots.When #19779 merges, the fix to look at: on a trusted live session list, drop any
mc-unread-orphaned:*/mc-unread-arrival:*key whose slot is not in that list, but skip a slot another window is reading right now so its marker survives. That guard is the part that needs a test across two windows.Labelled
needs-investigation, blocked on #19779.buluoray commentedon Oct 26, 2026
🤖 Kiro Crew Auto-Pipeline [operator: buluoray#ce473fca]: this issue is now claimed by buluoray#ce473fca's instance.
A worker will diagnose this and open a draft PR scoped to the issue's tier, or leave a written recommendation if the right call is to rescope or not change anything. The draft is not marked ready until the owner decides.
buluoray commentedon Oct 26, 2026
🤖 Kiro Crew Auto-Pipeline [operator: buluoray#ce473fca]: Parked, no PR. This issue depends on #19779, which is still open: the
mc-unread-orphaned:<slot>andmc-unread-arrival:<slot>keys exist only on that branch, not on main (5285bc2), and #19779's own cleanup is bounded to the slots this window had listed, so it leaves the two delete cases here as a follow-up by design.#19779 is also held for a maintainer ruling between keeping the tombstone protocol and a one-time versioned drop of the saved record. If the versioned drop is chosen, these per-session keys go away and this issue becomes moot. If the protocol stays, the fix lands after #19779 merges: on a trusted live session list, sweep every
mc-unread-orphaned:*/mc-unread-arrival:*key whose slot is not in the list, skipping a slot another window is reading at that moment so its marker survives.Labelled
parked,claimedremoved; the assignee picks this up once #19779 is decided and merged.buluoray commentedon Oct 27, 2026
🤖 Kiro Crew Auto-Pipeline [operator: buluoray#ce473fca]: Update on the blocker. #19779 was closed without merging on 2026-10-27, in favour of #19782. #19782's diff does not add the
mc-unread-orphaned:<slot>ormc-unread-arrival:<slot>keys, and neither key exists on main (6adda68e8a).So if #19782 merges as it stands, the two leaks described here cannot happen, and this issue can be closed as moot. If a later change brings the per-session keys back, the sweep described above still applies. Leaving it open and
parkeduntil #19782 is decided.