bridge_list keeps stale installedVersion/devPinned after bridge_install and bridge_dev_mode (fusion360 1.10.0 on three boxes)

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

After bridge_install {manifestUrl: <insiders fusion-bridge version.json>, force:true} succeeds at 1.10.0, bridge_list keeps reporting the previous numbers for the fusion360 bridge, and on a box whose dev pin was lifted with bridge_dev_mode {pinned:false} it keeps reporting devPinned:true as well. Seen today on three boxes at once:

Box	cache BRIDGE_VERSION	running exe (fusion_readiness.bridgeVersion)	bridge_list installedVersion / devPinned
ConfRoomROG	1.10.0	1.10.0	1.9.365 / true (unpinned an hour ago)
arav-rog	1.10.0	1.10.0	1.9.370 / false
AdomLapper	1.10.0	1.10.0	1.10.0-dev.routing.5 / true (unpinned minutes ago)

refresh_bridges {} on each box did not change the rows. The install reply itself says version 1.10.0 with method in_place_merge, and winvm's row moved to 1.10.0 on the running-exe read but not in the list. So the cache and the process are right and the list is stale telemetry, which makes it unusable as the acceptance view for an installed release (adom/fusion-bridge#80 is the report from the acceptance thread). Ask: reconcile installedVersion, runningVersion, latest, versionDrift and devPinned in bridge_list from the cache manifest and the live process after an install or a pin change, or say in the row that it is a cached snapshot and when it was taken.

2 Replies

John Lauer · 2mo ago

Fixed in ab 2.1.70. Two causes. (1) devPinned:true after unpinning: the threads sent bridge_dev_mode {pinned:false}; the verb read only on, and a missing on defaulted to true, so the unpin re-pinned. bridge_dev_mode now accepts on | pinned | enabled and refuses a call naming none of them (bad_args) instead of guessing. (2) stale installedVersion: bridge_list served the sweep's staleness snapshot (refreshed at launch and every 4h), not the cache. installedVersion is now read from the cache dir at list time (bridge.json, else BRIDGE_VERSION) with installedVersionSource: cache, and versionDrift is recomputed against the live process version; an install shows in the very next list. Proved on AdomLapper 2.1.70: fusion360 row installedVersion 1.10.2 from cache right after install; kicad pin and unpin reflected immediately.

John Lauer closed this · 2mo ago

John Lauer · 2mo ago

Confirmed on ab 2.1.71 across ConfRoomROG, AdomLapper, winvm and arav-rog: after bridge_install of fusion-bridge 1.10.4 the fusion360 row showed installedVersion 1.10.4 (installedVersionSource cache) and runningVersion 1.10.4 in the very next bridge_list, and the four unpins with bridge_dev_mode {on:false} read back devPinned false. One related gap went to #162: runningVersion matched even though the running image was the Python server.py, not the exe.