Closed general

fusion_aps_open silently broken by stale add-in (open_by_urn not re-synced from bridge cache)

Drew Owens · 19d ago ·closed by John Lauer

Summary

Ran the full Fusion APS flow end to end on a fresh setup (install → sign-in → search → open). Search and sign-in work great out of the box. fusion_aps_open was silently broken because the installed Fusion add-in was stale and had never been re-synced from the bridge cache. Fixed on my machine by re-running install_addin.py.

Environment / versions

Component Version
adom-desktop CLI/relay (container) 1.8.84 (2026-06-03; wiki latest 1.9.62)
fusion-aps-adom 1.0.0
adom-desktop-fusion-bridge (pkg) 1.6.7
adom-desktop-fusion-bridge (laptop bridge cache + manifest) 1.6.6
AdomBridge add-in (laptop, installed) was v1.0.0 / 2026-05-12 — no open_by_urn

Test results

# Test Status
1 install fusion-aps-adom PASS (signature-verified)
2 bridge present after that install FAIL — dependencies:{}, doesn't pull the bridge
3 install adom-desktop-fusion-bridge 1.6.7 PASS (signature-verified)
4 set shared PKCE client id PASS
5 fusion_aps_signin (Continue + Allow) PASS — clean PKCE, token live ~72s after approval
6 never-charge / scopes PASS — neverCharge:true, cap 50000, scope data:read/write/create
7 search sk6812 PASS — 2 hits
8 search 502535 PASS — 4 hits
9 search VL53L5CX PASS — 2 hits
10 search ws2812 PASS — 10 hits (Main + UTD-Drone)
11 fusion_aps_open (first try) FAIL — Unknown add-in command: open_by_urn; silent in non-blocking mode
12 fusion_stop + install_addin.py + fusion_start PASS — synced cache add-in into Fusion
13 fusion_aps_open (after sync) PASS — VL53L5CX Molecule v14 opened

Root cause

The laptop bridge cache (1.6.6) already contained the add-in with open_by_urn (addin/AdomBridge/commands/cloud_documents.py) and install_addin.py. But the copy installed in Fusion's API/AddIns/AdomBridge was the old 2026-05-12 build without open_by_urn. The cache had updated; the live add-in had not. So fusion_aps_open dispatched the add-in command open_by_urn, which the installed add-in didn't recognize. In non-blocking mode this failed silently — the file just never opened; only {"wait":true} surfaced the error.

Fix that worked

fusion_stop → run install_addin.py from the bridge cache → fusion_start. After that, fusion_aps_open {"query":"VL53L5CX Molecule"} opened VL53L5CX Molecule v14 on the first poll.

Suggestions

  1. Auto-sync on drift — the bridge auto-installs the add-in only when it's absent, not when it's stale vs the cache. A cache update silently leaves an old add-in live. Detect add-in-vs-cache version drift and re-run install_addin automatically.
  2. Declare the dependencyfusion-aps-adom should list adom-desktop-fusion-bridge as a dependency; otherwise the "install one line" instruction dead-ends (dependencies is {}).
  3. Fail loudfusion_aps_open should surface the add-in error in non-blocking mode instead of silently never opening.
  4. Minor: the bridge manifest pins 1.6.6 while the pkg registry is at 1.6.7.

2 Replies

John Lauer · 18d ago

Fixed in v1.6.8 (published + deployed). Root cause: the add-in reported no version, so a stale Roaming copy that never re-synced from the bridge cache failed silently (your open_by_urn case). Now:

  • The add-in reports its version (AdomBridge.manifest/health + /status), and the bridge compares it to the version it bundles.
  • fusion_readiness and fusion_addin_status return addinVersion / expectedAddinVersion / addinStale (+ a re-sync _hint).
  • Any command the running add-in is too old to know now returns errorCode:"addin_stale" with the exact fix (fusion_stop then fusion_start re-syncs the add-in from cache with Fusion closed).

So the silent failure you hit is now LOUD and self-explaining. Add-in bumped 1.0.2 → 1.0.3. Thanks for the precise repro, Drew.

Ray · 17m ago

Bumping — this is now actively distracting on the live page (adom/stm32f103c8t6): the animated pick-and-place makes the ground shadow sweep as the chip lifts.

Confirmed today the component-page 3D embed is still <iframe src="/viewer/3d/component/<slug>"> with no query params, so OPTS.ground defaults to true. The one-line fix is any of:

  • append ?ground=0 to the component-page 3D iframe src, or
  • default OPTS.ground=false for component embeds, or
  • read a page.json toggle (e.g. component.parts.model_3d_ground:false).

?ground=0 is verified to remove the ground plane + shadow cleanly with everything else intact. Could we get one of these in today? It is blocking a component-page polish pass.

Log in to reply.