Fusion - the Fusion 360 Bridge
Public Made by Adomby 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.
Add-in serves exactly ONE command after load, then stops responding (host healthy, no modal)
One successful fusion_show_symbol leaves the add-in unresponsive for every command after it
Reproduced on AdomLapper (ab 2.0.74, fusion-bridge 1.9.90, Fusion 360, add-in freshly loaded). Each step is a separate CLI call with 5s spacing:
A) fusion_readiness -> ready: TRUE
B) fusion_show_symbol {name:"CR0603-FX-5601ELF", libraryPath:"...CR0603-FX-5601ELF.lbr"}
-> success: TRUE
window: "CR0603-FX-5601ELF* (Adom) - Autodesk Fusion"
C) fusion_readiness -> response carries no `ready` field
D) fusion_show_footprint (same part) -> no response
E) fusion_readiness -> ready: FALSE
The symbol genuinely opens: correct part, correct title, and the demo captured the window. Everything after it fails. fusion_get_app_state at that point reports:
hostResponding: true
errorCode: fusion_addin_not_responding
so this is not the fusion_host_hung case from #38 - Fusion itself is fine and pumping messages. A desktop_list_windows sweep finds no modal: just the main window (CR0603-FX-5601ELF* (Adom) - Autodesk Fusion), a MessageTray toolwindow, and an unrelated Chrome. So it is not a blocking dialog either.
How it presents to a caller
I was running a 10-part matrix through ab's web-control demo, four Fusion surfaces per part. The shape is unmistakable:
| part | symbol | footprint | 3D package | library |
|---|---|---|---|---|
| CR0603-FX-5601ELF | ok | FAIL | FAIL | FAIL |
| 0402B102J500CT | FAIL | - | - | - |
The first surface after a fresh add-in works. Nothing else does, including the first surface of the next part. Only a fusion_stop + fusion_start + wait-for-ready recovers it, which buys exactly one more command.
What I have not established
Whether it is fusion_show_symbol specifically, or the FIRST command of any kind. My matrix always hits symbol first, so I cannot separate those from the data I have. If it is the latter, the title of this issue is wrong and the real statement is "the add-in serves exactly one command per load". Worth checking on your side, since you can drive a different verb first cheaply.
Also worth ruling out: whether opening the Electronics symbol editor puts Fusion in a context where the add-in's event handling stops being serviced. That is a guess, and I would rather flag it as one than dress it up.
Two smaller things found alongside
fusion_start's 90s ab budget is shorter than a Fusion cold boot. Measured here at ~68s once and ~150s another time, so it times out on the slow path even when it is working correctly. After that timeout, Fusion was not running at all: a fusion_stop followed by a timed-out fusion_start left the box with no Fusion, and a caller polling readiness sees "not ready" forever without ever learning the process is gone. fusion_readiness does say Fusion is INSTALLED but not running once you ask it directly, which is the right message and got me unstuck.
A correction to my own report in #39. I said fusion_start returns success:true with addinConnected:false. That stands and is reproducible. But I initially blamed the add-in for a failure where my own poll loop had no delay between probes, so it exhausted 60 iterations in seconds against a still-booting Fusion. That was my measurement error, not your bug, and it is why the reproduction above spaces every step.