Updater reaped the KiCad bridge the same second a call reached it (regression of #98?)

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

Colby Knox · 5d ago ·closed by Colby Knox

The updater reaped the KiCad bridge to apply 1.0.100 -> 1.0.104 at the same second a call reached it. This looks like a regression of #98, or a gap the busy probe from 2.0.84 does not cover.

Colby-ROG2, Adom Bridge 2.1.185, 2026-11-05 (UTC), from bridge_audit and bridge_log_read kicad:

20:40:56 kicad_install_library_bundle from the wiki's Cloud Library page: success, 6.7 s.
20:41:00 [ab] spawned process pid 2976 (kicad-bridge.exe)
20:41:03 kicad_show_library from the same page starts.
20:41:03 [ab] REAPED by ab: the bridge held its cache directory open (os error 32) while an update was being applied, so ab could not swap the files without stopping it first
20:41:04 [ab] EARLY-EXIT: spawned pid 2976 (kicad-bridge.exe) is GONE ~4149 ms after spawn
20:43:13 kicad_show_library fails: timed_out after 130011 ms.

What the user saw: the install finished, but KiCad stayed on its start page and never opened the library. The page then sat for the full 130 s budget, so a re-export that took about 10 s the day before took several minutes.

Afterwards bridge_info kicad reports installedVersion 1.0.104, status stopped, runningVersion null. The only banner in kicad.log is v1.0.100 listening on 127.0.0.1:49375.

Why #98's fix may not cover it: the busy probe runs before the reap, and a call that ab is about to forward, or is already forwarding, is not something the bridge can report yet. ab routes every call itself, so it already knows when one is in flight.

Ask:

Do not reap a bridge while ab has a call in flight to it, whatever its health endpoint says.
A call that arrives during the swap waits for the new process (or gets a retryable error right away), instead of hanging until its budget runs out.
Is the spawn at 20:41:00 expected? Something spawned a second kicad-bridge.exe four seconds before the reap, and it exited on its own.

The wiki page now retries the show once after a failure and stops waiting for the picture after 45 s, so users are covered either way. The fix still belongs here.

1 Reply

Colby Knox marked this in progress · 1d ago

Colby Knox · 1d ago

Fixed in Adom Bridge 2.1.188 (insiders now; public at the next promotion).

ab now counts the calls it forwards to each bridge. An automatic update waits up to 20 s for them to finish, then defers to the next check (current_deferred_busy) instead of stopping the bridge. The os error 32 path no longer reaps a bridge that reports busy.
A call that arrives during a swap waits for it and reaches the new process. Past 60 s it gets a retryable bridge_updating.
The second spawn was most likely a call whose health probe missed while the bridge was busy, which made ab replace a live bridge. ab now leaves a busy bridge running (retryable bridge_busy) and logs why before it ever replaces one. The Nov 5 audit had rotated, so I could not confirm this from logs.

Verified on a test machine with Hydrogen running: a 45 s call held through an update (same pid, finished), the update deferred, and a call made mid-swap landed on the new version.

Colby Knox closed this · 1d ago