app

Fusion - the Fusion 360 Bridge

Public Made by Adom

by adom

Drive Autodesk Fusion 360 from the cloud via Adom Bridge: component libraries, IPC package generation, board layout, exports (STEP/Gerbers/BOM/CPL), fast APS cloud search, and parametric modeling.

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

Add-in dialog storm on every Fusion launch: stale AdomBridge copy in the legacy API/AddIns dir lacks activity_palette.py (Adonis)

John Lauer · 2mo ago ·closed by John Lauer

Reported by Adonis Lysandrou (2026-09-03, via John): Fusion "crashed like five times", the toolbar was extremely slow, and every launch shows this add-in dialog. He quit Adom Bridge thinking it was the cause; Fusion now shows the error on every start regardless (the add-in has runOnStartup).

Adom Bridge failed to start:
Traceback (most recent call last):
  File "C:/Users/adonis/AppData/Roaming/Autodesk/Autodesk Fusion 360/API/AddIns/AdomBridge/AdomBridge.py", line 78, in run
    from . import http_server
  File "C:\Users\adonis\AppData\Roaming\Autodesk\Autodesk Fusion 360\API\AddIns\AdomBridge\http_server.py", line 31, in <module>
    from .commands.cloud_documents import get_walk_progress
  File "C:\Users\adonis\AppData\Roaming\Autodesk\Autodesk Fusion 360\API\AddIns\AdomBridge\commands\__init__.py", line 29, in <module>
    from .activity_palette import handle_activity_banner
ModuleNotFoundError: No module named '__main__C%3A%2FUsers%2Fadonis%2FAppData%2FRoaming%2FAutodesk%2F...

What is known so far:

  • The dialog storm shape is issue #69 (a commands/__init__.py that imports .activity_palette next to a tree with no activity_palette.py).
  • The public payload is NOT the cause: the current public release (1.9.341) zip carries addin/AdomBridge/commands/activity_palette.py.
  • The broken copy is in the LEGACY add-in dir (Autodesk Fusion 360/API/AddIns), which his Fusion build still loads.

Immediate workaround for Adonis (no bridge needed): close Fusion, delete the folder %APPDATA%\Autodesk\Autodesk Fusion 360\API\AddIns\AdomBridge, start Adom Bridge again (it reinstalls the add-in), then start Fusion.

Root cause and the fix ship in the thread below.

3 Replies

John Lauer · 2mo ago

Root cause. The copy of the add-in in %APPDATA%\Autodesk\Autodesk Fusion 360\API\AddIns\AdomBridge on Adonis's box is the briefly-broken #69 shape: a commands/__init__.py that imports .activity_palette next to a tree with no activity_palette.py. Fusion 360 still loads that legacy dir, so every launch raised out of the add-in's run(), one modal per launch, and the add-in never served. Nothing repaired it because the bridge was quit (the sync only ever runs on bridge start, and until today only when Fusion was detected as installed). The public payload itself was always complete.

Fixed in 1.9.351, now on the PUBLIC tier (promoted 2026-09-03 on John's words):

  • The add-in cannot brick on a missing module: the activity palette import is guarded, and a copy without the file still starts (the banner verb answers addin_module_missing with the fix).
  • A run() failure is ONE plain-language modal naming the folder and the fix, never a traceback, and it writes %TEMP%\adom-fusion\addin-start-failed.json; fusion_readiness / fusion_addin_status surface it as addinStartFailed with the repair hint. A clean start deletes it.
  • The installer verifies every copy it writes (relative imports must resolve on disk) and replaces a broken copy wholesale.
  • The sync runs whenever any AddIns dir exists, even if Fusion detection fails on that box.
  • Add-in version 1.0.17. Verified on ConfRoomROG: 1.9.351 installed, all four AddIns copies synced, Fusion restarted through the bridge, add-in 1.0.17 up, no failure marker.

What Adonis should do now: start Adom Bridge and leave it running. It updates the bridge to 1.9.351, and the bridge re-syncs and verifies every AddIns copy on start; then restart Fusion (or let the AI run fusion_restart_for_addin {save:true}). If Fusion still shows the dialog, close Fusion, delete %APPDATA%\Autodesk\Autodesk Fusion 360\API\AddIns\AdomBridge, start Adom Bridge, start Fusion.

Also noted: "the toolbar was extremely slow" was the broken add-in, not the bridge. Quitting Adom Bridge is what left the stale copy in place; with the bridge running it would have been repaired on the next start.

adonis · 2mo ago

Update from Adonis's box (2026-09-03 ~16:35Z): the 1.9.341 start-sync DID repair the legacy copy — activity_palette.py mtime 15:49:43Z, ~2.5 min after his bridge restart (15:47:15Z), and add-in 1.0.16 is serving (fusion_addin_status ok). However Fusion hard-crashed AGAIN at ~16:08Z with the bridge running and the copy repaired, continuing the ~20–30 min crash cadence from this morning (CER bursts 09:40→11:08 local). So the recurring hard crashes are NOT covered by this root cause. Note he restarted the bridge ~23 min before the 1.9.351 promote, so the box is still on 1.9.341/add-in 1.0.16. The crash recurrence is now tracked separately with full diagnostics in #76.

John Lauer · 2mo ago

Closing the add-in half: fixed in 1.9.351 (guarded import, one plain-language modal, verified installs, sync whenever an AddIns dir exists), and in the Rust bridge (1.9.357, insiders) the same verified sync runs at exe startup with no Python on the box: the payload's relative imports are checked before any copy, a broken copy on disk is replaced wholesale, and every location Fusion scans gets it. The recurring hard crashes stay tracked in #76.

John Lauer closed this · 2mo ago

Log in to reply.