Fusion - the Fusion 360 Bridge

fusion-lane: confirmed as a bridge bug. Thanks for the detailed report, Andy. It isn't fixed by anything released since 1.13.21; the current public build is 1.13.38. Taking it first thing next session. What's wrong, from your report and the code:

1. The Open dialog is found but never driven. The File name box is never filled and submitted. So the open_dialog_stuck reply, and its hint about space-free folders, fires even though your inputs were right.
2. The reply claims a cancel it didn't achieve. The desktop_close_window after the wait doesn't close Fusion's native Open dialog, and the verb doesn't check that the dialog is gone before saying so.
3. fusion_dismiss_blocking_dialogs and fusion_check_dialogs disagree. Check lists the native Open dialog (#32770), but dismiss doesn't count it as blocking.
4. The two empty Untitled documents from the failed import aren't closed.

The fix (next session):

• fill the File name box with the full path and submit, verified by the dialog going away;
• if that fails, close the dialog and confirm it's gone before replying;
• make dismiss_blocking_dialogs close a leftover native Open dialog;
• close the seed Untitled documents. I'll test it on the shared laptop with fusion_board_seed output, as AI Flow calls it, and post the result here.

Until then, the unblock that works, as you found: fusion_check_dialogs gives the dialog's hwnd, fusion_close_window {hwnd} closes it, and then close the empty Untitled documents. The verb's dialog-free routes (fusion_schematic {action:"open"}, fusion_open_board) don't give you a linked schematic and board with placed parts, so they aren't a substitute for AI Flow's step.

Fixed and public: fusion-bridge 1.13.41 (add-in 1.0.30).

What changed:

• The Open dialog is filled. The File name box is set by three selectors in turn (its name, the common dialog's control id 1148, the dialog's first Edit), each submitted, until the dialog takes the path.
• No false "cancelled". A dialog that won't take the path is closed with its Cancel button, then WM_CLOSE. The reply says it's closed only once it's gone (dialogClosed, closedBy); otherwise it names the dialog's hwnd as still open.
• No leftover documents. The empty Untitled documents a failed import opened are closed (untitledClosed).
• fusion_dismiss_blocking_dialogs closes native Open/Save dialogs, the ones fusion_check_dialogs lists. It rescans, because a cancelled import opens its .brd dialog right after the .sch one.
• The wait for the new design works. An import that worked used to be reported as nothing_instantiated: the wait compared the workspace's name, and 1.13.38 had started answering its id. It accepts both now, and add-in 1.0.30 answers the name again.

Checked live on our test laptop, with a .sch and .brd pair staged in a space-free folder and the same two calls AI Flow makes:

• fusion_new_electronics_from_eagle returned success: true, both files imported, 109 of 109 parts placed, and no dialog left on screen.
• A deliberately abandoned import's two chained Open dialogs were both closed by one fusion_dismiss_blocking_dialogs, and Fusion answered again.

To get it: let Adom Bridge update the Fusion bridge to 1.13.41, then restart Fusion once so it loads add-in 1.0.30 (fusion_restart_for_addin saves open work first). If AI Flow still hits it after that, reopen this issue with the import status reply.

Still failing on fusion-bridge 1.13.41 / add-in 1.0.30 (1 of 1 attempts, 2026-10-30 23:43 to 23:44 UTC).

Environment (verified right before the run)

• fusion_status (alias of fusion_readiness): bridgeVersion 1.13.41, addinVersion 1.0.30, expectedAddinVersion 1.0.30, addinStale false, READY.
• Fusion had been restarted after the update. Clean session: fusion_get_app_state showed 1 document (the default Untitled design, unmodified), fusion_check_dialogs showed 0 dialogs.
• Caller: adom-aiflow 0.2.26, adom-aiflow fusion schematic (Fusion lane) on Windows 11, called from the Adom-Workspace WSL container. Same seed flow as the original report: fusion_board_seed writes Seed.sch and Seed.brd into one space-free folder on the C drive (both files present), then fusion_new_electronics_from_eagle and the fusion_eagle_import_status poll.

Exact error text (as surfaced by AI Flow)

ERROR: the design import did not finish: Fusion's Open dialog did not take 'Seed.sch' (the File name box could not be set); the bridge closed the dialog (WM_CLOSE) and the empty documents the import had opened.
Hint: Start from a clean Fusion session (save and close half-finished designs) and run this again.

Actual

• The native Open dialog (hwnd 5971574, title "Open", filter "All supported files") stayed open, now sitting at Downloads, with an empty File name box. The path was never entered.
• fusion_check_dialogs still listed it as file_dialog with resolution "cancelled safely with WM_CLOSE", but it was still on screen, so the reply's "the bridge closed the dialog" was not true.
• fusion_get_app_state returned main_thread_busy ("Fusion main thread busy ? get_app_state running for 6.2s.") while the dialog was up.
• Two empty Untitled electronics documents remained open, so untitledClosed did not happen either.
• Note: the UI Automation button list for the dialog (below) has no "Open", "Cancel" or "File name" entries, which may be why none of the File name selectors or the Cancel click took effect.
• As before, only fusion_close_window {hwnd} sent by hand cleared the dialog and freed Fusion; the two empty documents were then closed with fusion_close_document {save:false}.

fusion_check_dialogs reply taken right after the failure:

{
  "count": 1,
  "dialogs": [
    {
      "buttons": ["&Help", "Details", "View Slider", "Organize", "New folder", "Line up", "Page up", "Page down", "Line down"],
      "category": "file_dialog",
      "hwnd": 5971574,
      "resolution": "a native Windows Open/Save dialog (left by a dialog-driven import or a manual action): cancelled safely with WM_CLOSE, nothing is saved or discarded",
      "text": "Command Module Preview pane Control Host Navigation Pane Vertical Position Desktop Home Gallery Start of Quick Access - Desktop (pinned) Downloads (pinned) Documents (pinned)",
      "title": "Open"
    }
  ],
  "durationMs": 400,
  "error": "",
  "output": "1 dialog(s) open",
  "schemaVersion": 1,
  "shell": "rust",
  "status": "ok",
  "statusVerb": "fusion_get_app_state",
  "success": true,
  "timeoutSeconds": 60
}

Import status reply: not captured (AI Flow gap)

The import status reply you asked for (errorCode, dialogClosed, closedBy, untitledClosed) could not be captured. adom-aiflow fusion schematic only prints the error string above and does not surface the import runId, and the bridge logs on the PC hold no record of it, so fusion_eagle_import_status called directly returns:

{"error":"runId is required (fusion_new_electronics_from_eagle returns it).","errorCode":"run_id_required","status":"error","success":false}

Request: please have AI Flow pass the runId and the full fusion_eagle_import_status reply through (printed or written into the run folder) so the next report can include it. Alternatively, a way to look up the last import's status without a runId would work.

History

• 4 of 4 failures on 1.13.14 to 1.13.21 (original report above).
• 1 of 1 failure on 1.13.41 / add-in 1.0.30 (this comment), from a clean session after the Fusion restart. The error text changed (it now says "the File name box could not be set"), so the new fill path is running, but it does not fill the box, and the close and cleanup steps still don't take effect.

No retry was made; Fusion was left clean (1 document, 0 dialogs).

Found it, Andy. Fixed and public in fusion-bridge 1.13.44. Thanks for the precise report. The UIA button list you included pointed the right way.

Cause on your PC. Adom Bridge gates UI Automation and keystrokes behind its shell approval, and that includes a bridge filling in a dialog. On a PC where that approval isn't on, every way of entering the path was refused (needs_approval), so the File name box stayed empty. We reproduced it exactly on our test laptop with approval off. The reply also said the dialog was closed while one was still on screen. That was the importer opening its .brd Open dialog as soon as the .sch one was cancelled.

What 1.13.44 does:

• Asks before opening any dialog. If approval isn't on:
  • the bridge asks Adom Bridge for it, and the prompt shows in the Adom Bridge window, its notification, or Hydrogen;
  • the start reply carries needsApproval: true and a tellUser sentence;
  • fusion_eagle_import_status reads waiting_for_approval. It waits for the click. With no approval it stops with needs_approval and opens no dialog, so Fusion is never blocked.
• Types the path if UI Automation can't set the box, and records each attempt's error (typeErrors).
• Closes the whole dialog chain on a failure, then the empty Untitled documents, and says "closed" only when no dialog is left.
• fusion_eagle_import_status with no runId answers the latest import, so you can read the full reply even though AI Flow drops the runId.

Checked live on the test laptop, with the same two calls AI Flow makes:

• approval off: needs_approval, no dialog, Fusion untouched;
• approval on: success, 109 of 109 parts placed, no dialog left.

For you:

1. Let the Fusion bridge update to 1.13.44. No Fusion restart is needed if you're already on add-in 1.0.30.
2. When the import asks, click Approve in Adom Bridge. Choose Auto (or Settings > Shell Commands) if you don't want to be asked each time.

If it still fails, reopen this with fusion_eagle_import_status {}'s reply.