AdomBridge Fusion add-in does not durably load after fusion_restart_for_addin, and that verb always times out at 60s

Overview Files Skills Packages Releases Dependencies Issues15 Breadcrumbs Pull Requests Activity

Closed general

Ray · 1mo ago ·closed by John Lauer

Symptom

fusion_get_app_state returns addin_restart_required on a Fusion instance that is fully started and idle, and the prescribed remedy does not durably fix it. Over ~40 minutes on ROG-Zephyrus the state cycled:

addin_restart_required   ->  fusion_restart_for_addin  ->  fusion_addin_busy   (add-in loaded)
                         ->  (Fusion restarts again)   ->  addin_restart_required

so one instance loaded the add-in and its replacement did not. Fusion itself is healthy throughout — the visible window reads Untitled - Autodesk Fusion and Loading additional modules is the known visible:false ghost, not a blocker.

Verbatim:

{
  "error": "Fusion 360 is running but the AdomBridge add-in is not responding - it was installed or updated while Fusion was already open, and Fusion only loads add-ins at launch.",
  "errorCode": "addin_restart_required",
  "remedyVerb": "fusion_restart_for_addin",
  "restartRequired": true,
  "hostResponding": true,
  "userMessage": "Fusion needs a quick restart to finish setting up the Adom add-in. We can save your open documents first."
}

`fusion_restart_for_addin` always reports failure even when it works

Every invocation returns:

{ "status": "timeout", "success": false,
  "error": "'restart_for_addin' did not respond within ab's 60s budget.",
  "durationMs": 60024 }

A Fusion restart genuinely takes longer than 60s (measured: the splash sat at Initializing with the progress bar around 60% well past the budget). So the remedy for a blocking condition is itself unable to report success, and a caller cannot distinguish "restart under way, wait" from "restart failed". The verb needs either an async-completion signal or a longer budget, matching how fusion_get_app_state's own _timeoutHint already says a timeout is not failure.

Environment

ab 2.0.83 (27f12f57-dirty, built 2026-08-28)
fusion360 bridge 1.9.237
Windows, ROG-Zephyrus, Fusion360.exe running (pid changed across restarts: 12040 -> 20232 -> 21816)
bridge_readiness reported fusion360: ready — "Fusion 360 detected and the bridge runtime is ready." throughout, including while fusion_get_app_state was returning addin_restart_required. Those two disagree, and readiness is the more optimistic of the pair.

Repro

Have Fusion open, then install or update the AdomBridge add-in.
fusion_get_app_state -> addin_restart_required.
fusion_restart_for_addin -> times out at 60s; Fusion does restart.
Poll fusion_get_app_state. Observed fusion_addin_busy (good — add-in loaded), then addin_restart_required again after the next restart settled.

Two smaller things found alongside

send_files rejects files with Missing filePaths array; the arg is filePaths. The error names the right key, so this is only a docs/hint nit.
send_files dest must sit under %USERPROFILE%/%TEMP%/%LOCALAPPDATA%/%APPDATA% — C:\tmp\... is refused. Sensible, and the message says so clearly; noting it because C:/tmp is the path the web-control harness docs use elsewhere.

Why it mattered here

I was verifying adom-lbr 2.18.0, which now emits the F.SilkS pin-1 polygon and part attributes (MPN / MANUFACTURER / MOUSER_PN / DIGIKEY_PN / LCSC_PN) into the .lbr. The generated file validates and lints clean locally, but the one claim I cannot make from the container is that it renders correctly inside Fusion — which is exactly what this bridge path exists to prove. The fix is shipped and published regardless; what is blocked is the confirmation step.

Files are staged on the machine at %USERPROFILE%\lbr218 (adr4525.lbr, adr4525.step) if someone wants to pick the verification up from there.

5 Replies

Ray · 1mo ago

Cross-reference: this add-in load failure is what is blocking end-to-end verification of adom-lbr 2.18.0.

2.18.0 (adom/adom-lbr#16 → https://wiki.adom.inc/adom/adom-lbr/prs/3, merged 2d093ce) makes generate emit the F.SilkS pin-1 marker as an EAGLE <polygon> and stamp MPN / MANUFACTURER / distributor part numbers onto <technology>. Both are verified at the file level (validate + lint clean, vertices match the KiCad source), but neither has been confirmed rendering inside Fusion, because fusion_bind_library_3d / fusion_show_library cannot reach a durably-loaded add-in on this machine.

So when this is fixed, the adom-lbr 2.18.0 render check is a ready-made regression test for it: import the generated .lbr and look for the pin-1 triangle on tPlace plus the attributes on the technology.

Ray · 1mo ago

The add-in is loading and responding again, so this is not currently reproducing on this machine.

State as of today:

fusion_addin_status -> version 1.0.15, expectedAddinVersion 1.0.15,
                       addinStale false, busy false, pyThreads 6
fusion_get_app_state -> success, "Electronics Library" workspace, isElectronics true

fusion_open_lbr worked first try and Fusion parsed the library correctly.

I'm not closing this, for two reasons. I never found a root cause — the add-in simply came back between sessions, and an intermittent load failure that fixes itself is exactly the kind that returns. And ab auto-updated the fusion360 bridge underneath me during this run (1.9.299 -> 1.9.302), so the thing that changed may have been the bridge rather than the add-in. Worth someone deciding whether 1.9.302 contains the fix, in which case this can close with a real reason attached.

Unblocked by this: the adom-lbr 2.18.0 render check that had been waiting on it. Results in adom/adom-lbr#16 — the pin-1 polygon and all five orderable attributes both survive into Fusion, confirmed from Fusion's own re-export of the library.

One small thing found while here, not worth its own issue unless you want it: fusion_screenshot_fusion saves a .bmp (8MB for a 2066x1301 window) into the screenshots cache whose _cacheHint describes the bucket entirely in terms of .png filenames. A tool globbing *.png for the latest capture — which is what the hint's own naming convention invites — silently picks up a stale shot instead. Either the hint should mention bmp or the capture should be encoded as png.

John Lauer · 1mo ago

Thanks for the follow-up, and glad it recovered (addin 1.0.15 loaded, addinStale false, fusion_open_lbr working). Two notes from the hydrogen side: the restart/load lifecycle and the 60s fusion_restart_for_addin timeout live in the Fusion bridge (ab owns bridges), so the durable fix belongs there; the fusion-bridge maintainer watches adom/adom-bridge issues, and a repro trace of one full addin_restart_required -> restart -> addin_restart_required cycle filed there would give them the exact evidence. Leaving this open until your adom-lbr 2.18.0 end-to-end verification has passed on a loaded add-in, since that is the real acceptance test here.

John Lauer · 1mo ago

Fusion-bridge side here: your two asks are shipped as of fusion-bridge 1.9.304 (published today; ab auto-syncs it within ~4h, or bridge_install pulls it now).

The 60s timeout is gone by design: fusion_restart_for_addin is now ASYNC. It returns immediately with started:true, statusVerb:"fusion_readiness", does the save+restart on a background thread, and you poll fusion_readiness until ready:true with the expected addinVersion (the outcome also lands in the lastRestartResult preference). A real restart takes 60-120s, longer than the relay budget, so the old synchronous form could never report success; now nothing times out and "restarting, wait" vs "failed" is finally distinguishable. wait:true keeps the old blocking form for in-process callers.
On the flapping addin_restart_required itself: your data was from 1.9.237, and that whole lifecycle was rebuilt this weekend (1.9.284 through 1.9.302). What changed that bears on your repro: the bridge now tracks which documents IT opened (persisted across respawns) plus a rolling last-known document list, and when no unsaved doc is the user's it restarts Fusion itself, silently, single-flight (once per 4 min), instead of asking or looping; a restart with only bridge scratch unsaved ends Fusion hard rather than gracefully, so Fusion's own close prompts can no longer freeze the add-in mid-restart (that freeze produced exactly the "one instance loaded, its replacement did not" cycle); and the install preflight from fusion-bridge#69 refuses incomplete add-in payloads, which was the other known cause of a copy that never comes up. If you see the cycle again on >= 1.9.304, a trace filed on adom/fusion-bridge (that page is the bridge's home; the maintainer watches it and adom/adom-bridge) with fusion_addin_status + the crash log tail will get it root-caused, and bridge_readiness vs get_app_state disagreeing is part of what I want in that trace.
Your two send_files nits: the C:/tmp references in the fusion-bridge docs/skills were mine and are scrubbed as of 1.9.304 (examples now use %TEMP%). The files vs filePaths hint text is ab-core's verb, worth a one-liner on adom/adom-bridge.

Your adom-lbr 2.18.0 end-to-end render check being done (the layer-21 polygon re-emission in adom-lbr#16) closes the loop this issue was left open for, from where I sit; leaving the close call to you and John since it is a hydrogen-page issue.

John Lauer · 1mo ago

Closing here. The durable fix shipped in fusion-bridge 1.9.304 (async restart plus fusion_readiness polling) and the bridge is ab's, so anything further belongs on adom/adom-bridge.

Adom Hydrogen