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.
Fusion process exits mid-run; readiness reports ready:false forever with running:false (needs a terminal fusion_not_running signal)
Fusion 360 keeps dying mid-run: the process disappears while the bridge is driving it
Fourth Fusion issue today, and the one blocking the library matrix. Reporting the pattern rather than a single call, because the individual verbs are not what is failing.
What happens
19:47 Fusion360 RUNNING, pid 60572, 2351 MB (confirmed via Win32_Process)
19:47 serial run starts: fusion_readiness -> fusion_show_symbol -> _footprint -> _3d_package
19:52 no images produced, readiness never returns ready
20:0x Fusion360 NOT RUNNING (process gone)
fusion_readiness -> {ready:false, running:false, installed:true}
hint: "Fusion is INSTALLED but not running - call fusion_start"
The process is simply gone. No hung Ghost window this time (that was #38), no modal, and the add-in did not merely stop answering (#40) - the whole application exited while the bridge was driving it.
This is at least the third distinct way Fusion has become undrivable on this box today:
| # | symptom | state |
|---|---|---|
| 38 | host hung, Windows Ghost window |
fixed 1.9.90 |
| 39 | fusion_start success:true with addinConnected:false |
fixed 1.9.93 |
| 40 | add-in appears to stop after one command (really a 546s surface) | 1.9.94 |
| this | process exits mid-run | open |
What I need from the bridge
A liveness signal that separates "not yet" from "gone". fusion_readiness returns ready:false for both a warming add-in and a dead application. It does carry running:false, and that field is the answer - but a caller polling ready alone (which is what the verb is named for) waits forever on a process that will never come back. My own script did exactly that and burned eight minutes waiting for a dead app. That is my bug to fix, and I have, but the shape of the response invites it: ready:false with running:false should be a terminal answer, not a "keep polling" answer. A distinct errorCode (fusion_not_running) on the readiness response would make it impossible to get wrong.
Whatever is killing it. I cannot tell from outside whether Fusion crashed on its own, or the bridge restarted it (1.9.93's warm path force-restarts) and the relaunch silently failed. If the bridge initiated a restart, the caller should be told - a restart that does not complete is indistinguishable from a crash, and both leave the caller polling.
Context
I am ralph-testing the web-control demo's library card across 10 parts. Each part must open a symbol, a footprint AND a 3D package, with a screenshot of each. KiCad completed 10/10 this way. Fusion has not completed a single part, and every failure so far has been the application's availability rather than the show verbs themselves - the one time it was genuinely drivable, fusion_show_symbol opened CR0603-FX-5601ELF* (Adom) correctly on the first try.
I will keep re-running until all 10 pass and will report each failure here as it happens.