AdomBridge add-in loads TWICE: Fusion scans both FusionAddins and 'Autodesk Fusion 360/API/AddIns' (suspected cause of frozen/invisible canvas)

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

Closed bug report

Muzzer · 24d ago ·closed by John Lauer

On NUCboxKB9 (fusion-bridge 1.11.39, add-in 1.0.20, Windows 11, AMD Radeon / Ryzen 5 5600U) Fusion's Scripts and Add-Ins dialog lists two AdomBridge 1.0.20 add-ins, both Running with Run on Startup ticked:

C:/Users/murra/AppData/Roaming/Autodesk/FusionAddins/AdomBridge
C:/Users/murra/AppData/Roaming/Autodesk/Autodesk Fusion 360/API/AddIns/AdomBridge

addin_dirs() (rust/os-win/src/lib.rs) installs into all three conventions on the assumption that "Fusion moved this dir across versions and silently ignores the others" (issue #63). This Fusion does not ignore them: it loads both copies, so two add-ins hook the same events, build the same palettes and contend for the localhost port.

Symptoms on this box today, all with the duplicate running:

Fusion 3D PCB view shows a frozen image of the 2D board editor (net names, via labels) on top of the 3D canvas; orbit/pan/zoom do nothing; minimise/restore reveals a black canvas underneath. Reproducible after rebuilding the 3D PCB.
After closing the electronics design, an ordinary mechanical design opens with no visible model and two sets of navigation toolbars, plus the Electronics 2D editor's bottom toolbar left on screen.
Frequent Add-in request failed ... 127.0.0.1:8774 ... did not properly respond timeouts on otherwise simple verbs.
After a clean Fusion restart a mechanical design orbits fine; the corruption came back later in the session.

Not yet proven that the duplicate is the cause: the user is now testing with both copies stopped. Suggest: before installing into a legacy dir, check which dirs this Fusion actually scans (or detect two registered AdomBridge entries) and keep exactly one; and have the add-in refuse to start a second instance (port already bound by another AdomBridge → log and exit).

2 Replies

John Lauer · 24d ago

Thanks, Muzzer, good catch. Fixed in fusion-bridge 1.11.44 (insiders now, public after sign-off): only one AdomBridge copy runs per Fusion.

What was wrong. Fusion loads both folders into one Python interpreter. Our test box showed the same thing: both copies were loaded. The second copy already quit when it found port 8774 taken, but too late. By then it had registered a handler on the same custom event as the serving copy. Stopping that second copy from the Scripts and Add-Ins dialog would then unregister the shared event and cut off the copy doing the work.

What changed. The first copy to start claims the Fusion process. Any other copy sees the claim and returns straight away, before it registers anything. It has no event, no server and no palette, and its stop() does nothing. A copy that fails to start gives up its claim, so a working sibling can take over on the next start.

Tested live on a Windows box with both folders installed:

The API/AddIns copy served, and the FusionAddins copy reported that it was standing down, with no event and no server.
Stopping the idle copy left the serving copy untouched: the bridge still answered, and a script still ran through the custom event.

Why both folders stay installed. Different Fusion builds scan different folders (#63 was a build that ignored one of them). Removing one could leave a user with no add-in after a Fusion update. Fusion's dialog will still list two entries, but the second one is idle.

The display symptoms (frozen 2D image over the 3D canvas, doubled navigation toolbars): the idle copy creates no UI, so it was unlikely to cause them, and we have not reproduced them. If they come back on 1.11.44, please open a new issue with a screenshot and the time. I am closing this one since the duplicate is handled.

John Lauer closed this · 24d ago

John Lauer · 24d ago

Update: 1.11.44 is now on the public channel, so a normal update picks up the single-copy fix.