Session summary: building Fusion library from 138 basic parts (2026-07-02)

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

Closed general

AravK · 19d ago ·closed by John Lauer

bug

Session Summary — Building Fusion 3D Library from Adom Basic Parts

Date: 2026-07-02
Goal: Download all 138 basic-part .lbr files from the wiki, send them to the desktop, open Fusion 360 via the bridge, and place parts in a schematic.

Blockers (2)

fusion_start 60s timeout too short for first launch. A fresh Fusion install takes 2–4 minutes to fully initialize (component downloads, updates, cloud sync). The bridge's 60-second dispatcher timeout expired on every attempt. Passing {"timeout": 300} had no effect — the dispatcher clamped it regardless.
AdomBridge add-in never appeared in Fusion's Scripts & Add-Ins. The add-in was installed to the correct path (AppData\Roaming\Autodesk\Autodesk Fusion\API\AddIns\AdomBridge) with runOnStartup: true in the manifest. Tried both a junction link and a direct file copy. Fusion never listed or loaded it — port 8774 never came online. All bridge automation was blocked. Had to fall back to manually importing the generated library.

Friction (4)

Basic parts skill had wrong paths for 10 parts. The adom-basic-parts skill maps all parts to bare slugs (e.g., <slug>), but 10 parts (all 8 Samsung CL21 0805 caps, one 0603 cap, one inductor) were published under aravk/<slug> instead. The skill marks them as "❌ no wiki page" when they actually have full pages with complete CAD assets.
Fusion crashed/restarted multiple times during first-time setup. Fusion closed itself at least twice — once for an auto-update, once from a "Not Responding" freeze. Each restart required re-waiting for the full splash-screen initialization (~20 minutes lost).
USE command didn't work for importing .lbr files. Typing USE <path> in the schematic command line either opened the library as a viewer (parts not placeable, "no selectable asset available") or failed on paths with spaces (error: can't open 360/). The EAGLE-era USE workflow doesn't map to Fusion Electronics.
No error feedback when the add-in silently fails to load. Fusion gave zero indication — no log, no error, no entry in the Scripts & Add-Ins list. The only signal was its absence.

What Actually Worked

The manual fallback path for importing .lbr files into Fusion Electronics:

Open the schematic editor
Open Library Manager (under the LIBRARY tab)
Click the Private Libraries tab
Click Import into Fusion Hub
Browse to and select the .lbr file

This workflow is not documented on the wiki bridge page. Worth adding as a fallback for when the add-in isn't available.

4 Replies

John Lauer · 19d ago

Thanks Arav - triaging both blockers (keeping this OPEN; they're real and not fully fixed).

Blocker 2 (add-in never loaded / port 8774 offline) - the critical one. I checked install_addin.py: it already targets BOTH AddIns paths (AppData/Roaming/Autodesk/**Autodesk Fusion**/API/AddIns and the older **Autodesk Fusion 360** variant), so the 2024 rebrand isn't the cause. If the folder + AdomBridge.manifest (runOnStartup:true) were in the right place and Fusion still never listed it, the usual culprits are: (a) Fusion was RUNNING at install time, so it never re-scanned AddIns - it only loads new add-ins on a fresh start (fusion_stop then fusion_start); (b) a junction/symlink AddIns folder (Fusion's scanner skips reparse points - you noted you tried a junction); (c) a partial copy (missing AdomBridge.py or a commands/ file). To pin it down I need your repro: after a clean install_addin.py + a full Fusion restart, what does GET http://127.0.0.1:8774/health return, and does Fusion's Scripts-and-Add-Ins > Add-Ins list show 'AdomBridge' at all? New in v1.6.8: the add-in now reports its version and the bridge flags addinStale/errorCode:addin_stale - so a mis-synced add-in is now LOUD instead of silent (issue #55), which should make this class of failure self-diagnosing.

Blocker 1 (fusion_start 60s timeout; {timeout:300} clamped). A first launch (2-4 min) exceeds AD's ~60s relay request cap - that cap is AD-core, so the bridge can't raise it; {timeout:300} can't win against it. The correct pattern (and what the v1.6.8 skill now teaches): treat a fusion_start that 'times out' at ~60s as still launching, then POLL fusion_readiness until ready:true rather than retrying fusion_start. I'm going to make fusion_start return promptly with a stillRunning+poll hint on a long first launch (statusVerb pattern) so this isn't a dead end - tracking that here.

Friction (basic-parts skill wrong paths for 10 parts): that's the adom-basic-parts skill's slug mapping (owned on that page), not the bridge - worth a breadcrumb/issue there; happy to file it.

Will update here once I ship the fusion_start return-and-poll change and once we nail the add-in-load repro.

John Lauer · 18d ago

Blocker 1 (fusion_start timeout) is FIXED in v1.6.9 (published + deployed). fusion_start no longer blocks past AD's ~60s relay cap on a slow first launch: it confirms the Fusion process, waits for the add-in only within a sub-cap budget, and if the add-in isn't up yet returns {success:true, stillLaunching:true, statusVerb:"fusion_readiness"} with a _hint to POLL fusion_readiness until ready:true (never re-call fusion_start). So a 2-4 min first launch is now a clean poll loop, not a dead end. The USER-skill cold-start table has a matching stillLaunching row.

Blocker 2 (add-in never loaded): I could not reproduce it from here, and I confirmed install_addin.py already targets both AddIns paths (the 'Autodesk Fusion' rebrand + the older 'Autodesk Fusion 360'), so it isn't a path bug. v1.6.8 also added add-in version self-reporting + addinStale/errorCode:addin_stale, so a mis-synced or non-loading add-in is now self-diagnosing rather than silent. That leaves the 'installed correctly but Fusion never lists it' case, which is almost always (a) Fusion was running at install time (it only scans AddIns on a fresh start) or (b) a junction'd AddIns folder (scanner skips reparse points) - both you hit.

Closing since the bridge-side blocker is fixed and the add-in-load path is now diagnosable on 1.6.9. Please reopen with the GET http://127.0.0.1:8774/health output + whether Fusion's Add-Ins list shows 'AdomBridge' if it recurs after a clean install + full Fusion restart on 1.6.9.

John Lauer · 18d ago

Reopening: I reproduced blocker 2 (add-in never loads) LIVE on a clean AD 1.9.74 VM (ADOMBASELINE). So this is NOT environment-specific to Arav's machine - it's real and reproducible.

Repro: fresh Fusion trial install, signed in, Fusion fully closed, add-in deployed to %APPDATA%\Autodesk\Autodesk Fusion\API\AddIns\AdomBridge (verified: AdomBridge.py + http_server.py + 17 command files + a valid AdomBridge.manifest with runOnStartup:true, type:addin, autodeskProduct:Fusion, supportedOS:windows), then launched Fusion fresh from the COMPLETE webdeploy folder. Fusion loads + signs in fine, but port 8774 never comes online - Fusion does not run the add-in despite runOnStartup:true.

Likely root cause: Fusion's manifest runOnStartup is only the DEFAULT for a newly-discovered add-in; Fusion's per-user add-in registry gates whether it actually runs, and a brand-new add-in stays disabled until it's Run once via Scripts and Add-Ins (Shift+S -> Add-Ins tab -> select AdomBridge -> Run, + tick Run on Startup). After that one-time enable it auto-loads every launch. This matches 'installed correctly but Fusion never lists/runs it'.

Fix direction (bridge/onboarding side): the first-install path can't rely on runOnStartup alone. Options: (a) drive the Scripts-and-Add-Ins panel once on first deploy to Run + enable it (GUI automation), or (b) write Fusion's add-in enabled-state directly so it auto-runs on next launch. I'll pursue this as the proper #63 fix. Filing the repro now so it's tracked with real detail.

John Lauer · 17d ago

ROOT CAUSE FOUND + FIXED in v1.6.14 (proven live on the fresh ADOMBASELINE install). Fusion MOVED its per-user add-in directory: 2025+ Fusion scans %APPDATA%\Autodesk\FusionAddins\ and silently ignores the legacy Autodesk Fusion[ 360]\API\AddIns\ dirs. Your install (and mine) put AdomBridge in the legacy dir - Fusion loaded fine, never ran the add-in, port 8774 stayed down, exactly what you reported. Moved to FusionAddins, it came up 20 seconds after a Fusion restart with zero manual enabling (runOnStartup honored) - no Scripts-and-Add-Ins dance needed at all.

Shipped in v1.6.14: install_addin.py installs/uninstalls to every known convention (FusionAddins + both legacy dirs - each Fusion version loads from the one it scans and ignores the rest), fusion_detect scans all of them, and the add-in-not-responding hints explain the moved-dir trap with a stable errorCode. Also baked in: the AI restarts Fusion itself (fusion_stop+fusion_start) - hints never tell the user to restart/enable anything. Both blockers in this report are now fixed (blocker 1 was the relay-cap dead-end, fixed in v1.6.9 with stillLaunching+poll). Closing. Thanks Arav - this report led straight to the root cause.