Bridge SDK change: every bridge now needs a <prefix>uninstall verb (for the uninstall cascade)

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed general

John Lauer · 3mo ago ·closed by John Lauer

Heads-up from the Adom Bridge (ab) thread: the Bridge SDK now requires every bridge to expose a <prefix>uninstall verb. Please add one. This shipped in the SDK skill with ab 2.0.28 (adom-wiki pkg install adom/adom-bridge, load adom-bridge-sdk), and this notice is the migration ask.

Why

An Adom employee reported that uninstalling left cruft on their machine. ab's uninstaller can remove ab's own files, but it has no way to clean up what a BRIDGE created — and bridges install state OUTSIDE ab's directory: a host-app add-in (the Fusion add-in lives in %APPDATA%, not ab's dir), per-bridge caches, downloaded runtimes/models, registry keys, temp dirs. Only the bridge knows where all of that is. So ab's uninstaller will CASCADE — enumerate the installed bridges and call each bridge's <prefix>uninstall before removing ab — and the whole ecosystem uninstalls cleanly.

What to add

A <prefix>uninstall verb (e.g. <yourprefix>_uninstall) that removes EVERYTHING your bridge created on the machine — your add-in/plugin files in host-app dirs, your caches, your registry entries, your temp files, anything outside ab's own bridges-cache (ab removes that). Requirements:

Idempotent and non-interactive — safe to call when already clean; NEVER prompt or block. It runs during a silent /S uninstall cascade, so a modal/prompt would hang the parent uninstaller. Route any message to your log, not a dialog.
Best-effort per item — one un-removable file must not abort the rest. Report what was and wasn't removed.
Scoped to YOUR OWN artifacts only — never touch the host app itself (do NOT uninstall KiCad/Fusion/Blender/the browser), other bridges, or user data/projects.

Wire-up

Declare it in your bridge.json: an uninstall field naming the verb (e.g. "uninstall": "fusion_uninstall"), so ab knows to call it during the cascade. If absent, ab logs that your bridge left cleanup to the user.
Add it to your describe catalog and your consumer skill like any other verb, with a rich _hint/_next in the OUTPUT.

Reference

Full contract: the adom-bridge-sdk skill (in the adom/adom-bridge pkg), section "REQUIRED: every bridge MUST expose a <prefix>uninstall verb." Reply here with a plan or any blockers. Thanks!

1 Reply

John Lauer · 2mo ago

Done - shipped and live, closing. The verb landed with the ab 2.0.35 cascade work and is verified against the current SDK contract point by point:

fusion_uninstall exists, declared in bridge.json as "uninstall": "fusion_uninstall" so ab's cascade finds it, and it is in the fusion_describe catalog.
Scope: removes exactly what this bridge plants outside its cache - the AdomBridge ADD-IN from all three historical Autodesk AddIns locations (FusionAddins, "Autodesk Fusion/API/AddIns", "Autodesk Fusion 360/API/AddIns"), plus the bridge's prefs (~~/.adom/fusion-bridge) and APS OAuth tokens (~~/.adom/fusion-aps). Fusion itself, other bridges, and user projects are never touched.
Idempotent, non-interactive, best-effort per item: no prompts ever; each path is attempted independently and reported in removed[]/skipped[]; already-clean is a clean success. If Fusion is RUNNING it holds the add-in files open - the response says so and names the remedy instead of hanging.
dryRun:true previews the exact removal set. Live receipt from AdomLapper today (bridge 1.9.42): dry run returned all 3 add-in dirs + both userdata dirs, skipped [], success true.
Covered by the daily verb suite (dryRun form) so it cannot silently regress.

John Lauer closed this · 2mo ago