Updater: a staging download that never starts leaves state=checking forever; every later update_check says 'Update available' but never re-stages (AdomLapper stuck on 2.1.93, 2.1.94 never landed in Temp)

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

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

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

AdomLapper, 2026-09-10 14:30 UTC, ab 2.1.93: the updater logged 'staging installer https://wiki.adom.inc/download/adom/adom-bridge/2.1.94/... -> %TEMP%\Adom.Bridge_2.1.94_windows_x64-setup.exe' and then nothing - no SHA256 line, no 'staged' line, and no file was ever created in Temp (2.1.90/2.1.91/2.1.93 installers are there, 2.1.94 is not). The laptop's network is fine (curl from the same box pulls the same URL at 2 MB/s). The next update_check calls (14:33 and later) log 'Update available: 2.1.93 -> 2.1.94' but never a second 'staging installer' line: update_status stays state=checking, updateReady=false, busy=false, and apply_update is refused. Around 14:36 the box also logged DNS failures (GrokBot host) and relay-shim pipe aborts, so the first request probably hung on connect/DNS. Fix: (1) wrap the staging download in a hard timeout (connect 20 s, overall 10 min, stall 60 s without bytes) and on any failure reset the state to idle with lastError set so the next update_check re-stages; (2) update_status must report that error (lastError, stagingSince) instead of a bare 'checking'; (3) a check that arrives while a staging is older than the timeout restarts it. The other three boxes staged the same build in under a minute.

2 Replies

John Lauer · 2mo ago

Fix shipped in 2.1.95 (insiders): download_and_stage streams the installer (connect 20 s, first byte 30 s, then it fails only after 60 s without bytes or 20 min total) instead of one 180 s client timeout on the whole transfer, and records last_stage_error, exposed as lastStageError in update_status (and last_stage_error on /update/status) so the box says WHY nothing is staged instead of a bare state=checking. Root cause on AdomLapper, from %LOCALAPPDATA%\inc.adom.bridge\logs\Adom Bridge.log: 'staging installer' at 14:30:05, then at 14:33:05 'update_check: background stage failed: read bytes: error decoding response body' - exactly the 180 s cap; the rollout loop only polled update_status afterwards, and a status poll never re-stages (only update_check or apply_update do), so the box sat there. Recovery was one update_check: staged and applied 2.1.94 in under two minutes on the same link (2 MB/s when measured). The rollout loops now re-issue update_check while updateReady stays false. Note for anyone reading these logs: the updater's failures are logged by the CALLER (app_lib::commands 'background stage failed'), not under app_lib::updater. Closing when the 2.1.95 smoke suite is green.

John Lauer · 2mo ago

Closing: 2.1.95 insiders on winvm, ConfRoomROG and AdomLapper (each staged and applied through the real path; the rollout loops re-issue update_check while updateReady stays false); smoke suite on 2.1.95: 60/60 executed, 0 unexpected failures (a first run had 3 relay-unreachable hits at T16-T18 caused by my own package refresh bouncing gallia's relay child mid-suite; rerun clean).

John Lauer closed this · 2mo ago