Adom Bridge

Correction from Drew: the Sep 1 to 2 occurrence was a manual REINSTALL of ab on the machine, not a self-update. A fresh install starting without a manually added bridge is expected, so incident 2 is withdrawn and the body is edited down to the single Aug 27 case (the CLI cannot retitle an issue, so please read past the stale "twice this week" title). What remains: during the 1.9 to 2.x migration, the catalog bridges survived but the manually installed puma-bridge (with a valid updateManifestUrl) was dropped. One data point, so treat this as a question about intended behavior as much as a bug report. Apologies for the churn; also ignore the two stray file attachments below, they were a CLI flag mistake while editing.

Answered + fixed in ab 2.1.7 (insiders; pkg published).

Root cause confirmed. The 1.9->2.x rename migration in the installer PREINSTALL copies only a few markers (embedded.json, hd-relay.json, hd-managed) from %LOCALAPPDATA%\Adom Desktop and then RMDir /r's the whole old dir — which held bridges-cache\. Catalog bridges (fusion/kicad/pup/native-browser/hd) survive because they are bundled in the NSIS and re-extracted; a MANUALLY installed bridge (puma-bridge) lived only in that cache, so it was deleted. That is the vanish you saw on essemtec-PC4203.

Answer to Q1: yes — a manually-installed bridge with an updateManifestUrl is supposed to survive. The install-URL sidecar (~/.adom/bridge-install-urls.json) is NOT under the deleted dir, so every manual bridge's install URL was still on disk the whole time; only the cache payload was lost.

Fix (general, not migration-specific): on launch ab now reconciles that sidecar against the registry — any bridge with a persisted install URL that is missing from the registry is reinstalled from its URL in the background (spawn_missing_bridge_reconcile, mirroring the autostart-artifact reconcile). So a box that crosses the migration, or loses its cache any other way, re-heals its manual bridges automatically on the next launch, no manual bridge_install needed. Logged as BRIDGE-RECONCILE: in startup.log.

Note this heals the SYMPTOM robustly; I did not also add cache-copying to the one-time rename PREINSTALL, since the sidecar-driven reinstall is the durable path and covers every lost-cache case, not just the rename.

Confirmed, and thank you for the thorough root cause. That matches what we saw exactly: the sidecar was intact the whole time (our install URL was never in question), while the cache payload under the old dir was gone, which is why the catalog bridges came back and ours did not.

Reconciling the install-URL sidecar against the registry on launch is the better fix than patching the one-time rename PREINSTALL, agreed. It also covers the case that bit us a second time this week: Drew reinstalled ab on the machine on Sep 1, which legitimately starts with no manually installed bridges, and today that meant another manual bridge_install to get puma_* verbs back. Under 2.1.7 that reinstall should self-heal from the sidecar too, which is a real operational win for us since this machine is the production line's only Puma.

Closing this. The ePlace PC is on 2.0.80 today, so I have not observed BRIDGE-RECONCILE: yet; I will watch startup.log for it when the machine picks up 2.1.7 and reopen or file fresh if a manual bridge still goes missing after a cache loss.