Boot-time AUMID prune wipes live thread keys before reloaded sessions re-stamp

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Measured during the 2.0.182 ladder proof: after a bridge respawn, reloaded sessions have _curAppId=null until their first stamp lands, and the 60s boot prune (and the 5-min sweep) treats every existing Adom.Pup.thread.* registry key as orphaned and deletes them, un-branding buttons until a re-stamp+nudge cycle completes. Also observed: reloaded sessions can stall in the tile-render DEFER loop for many minutes until a taskbarMode set forces a full brandSweep. Fix ideas: seed liveAppIds from the session files' last-known appIds at boot, and add a brandSweep retry-with-backoff for sessions whose tile render keeps failing.

2 Replies

John Lauer · 2mo ago

Fixed in 2.0.186: the prune (boot and 5-minute sweep both) now refuses to run while reloaded sessions exist and no identity stamp has landed since boot — so live thread keys can no longer be wiped during the respawn window. Once the first re-stamp lands, normal pruning resumes. The render-stall half (sessions stuck in the tile DEFER loop after a respawn) remains open work; tracking here.

John Lauer · 2mo ago

Both halves fixed in 2.0.250, verified on ConfRoomROG with real windows across a real respawn.

Half one — the prune wiping live keys. 2.0.186 already held the prune until the first stamp landed; that helped but still depended on in-memory state that a fresh boot does not have. The prune now also seeds its live set from the sessions persisted on DISK, two ways: the identity each window was wearing (a new appId field written into the session file at save time) and the thread AUMID its owner implies, computed with the same formula the stamp uses — which covers session files written before that field existed.

Measured on ConfRoomROG: three live windows (fusion-dashboard, kicad-dashboard, pup bridge maintenance), bridge killed and respawned onto 2.0.250, then waited out the 60s boot prune window:

sessions reloaded after respawn: ai-fusion-dashboard, cn-dash, kicad-dashboard
4 key(s) survived:
  Adom.Pup                                        <- the pinnable base launcher
  Adom.Pup.thread.fusion-dashboard-c0c901.t7
  Adom.Pup.thread.kicad-dashboard-2e3e06.t7
  Adom.Pup.thread.pup-bridge-maintenance-ac7484.t7

Every live thread key survived, and no prune line fired against them.

Half two — the tile-render DEFER stall. A deferred registration ("tile not ready") used to be terminal: the window stayed unbranded until unrelated churn or a manual taskbarMode flip forced another sweep, which is the "many minutes" you measured. A defer now schedules a bounded retry (4s, 8s, … capped at 60s, five attempts) and the counter clears the moment the art renders, so the tile lands on its own.

Battery on that machine after the change: selftest 13/13 GREEN, mode-ralph 8/8 GREEN (including both rapid-race rounds), icon audit clean.

One note: I could not run the same respawn test on AdomLapper because it dropped off the relay partway through this work (target_not_found, and adom-bridge targets lists only ConfRoomROG). Everything above was verified on ConfRoomROG; I will re-confirm on AdomLapper when it reconnects.

John Lauer closed this · 2mo ago