app

Fusion - the Fusion 360 Bridge

Public Made by Adom

by 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.

fusion360autodeskcadpcbexportsapsmodelingmechanicalassemblies
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity
Closed bug report

Readiness probe runs Electron.run DISPLAY and cancels the user's active Fusion command (from hydrogen#152)

Colby Knox · 11d ago ·edited ·closed by Colby Knox

Reported on Hydrogen: adom/hydrogen#152 (Glenn Jones, Hydrogen 1.0.666, Windows 11 Home 24H2). While Glenn works in Fusion, something keeps canceling what he is doing: a component move in progress snaps back to where it was, and a reply he is reading in Fusion's AI assistant is dismissed and he lands back in the UI. It started when he began using the bridge. He has not yet confirmed by stopping the bridge.

Hydrogen is ruled out. His Hydrogen log shows 9 focus changes in 12 hours and no Hydrogen timer that touches Fusion or the bridge.

Strongest lead, in this bridge: get_app_state (addin/AdomBridge/commands/app_state.py, still present in 1.13.37) runs real commands on Fusion's main thread:

ws = app.executeTextCommand("DebugCommands.ActiveWorkspace")
...
app.executeTextCommand("Electron.run DISPLAY")   # used as an "is Electronics active" test

Electron.run DISPLAY starts the EAGLE DISPLAY command. Starting any command in the Electronics editor terminates the one in progress, which matches "cancels the move and puts it back". get_app_state is also the bridge's readiness round-trip (_addin_round_trip_ready, _check_main_thread_blocked, the launch-progress watch, and many verb pre-checks), so anything that probes readiness on a cadence would cancel the user's command each time.

What I did not find: the caller that fires it on a timer. My local copy is 1.9.217 and I could not pull the current server.py, so please trace it in 1.13.x (dashboard status refresh, ab's statusVerb use, a watchdog or keepalive, or an AI thread polling fusion_get_app_state).

Suggested fix:

  1. Make the readiness probe side-effect free: read app.activeProduct.productType / app.activeDocument instead of running text commands, and decide "is Electronics" from the product type, never by running DISPLAY.
  2. Never run a command while the user has one active (app.userInterface.activeCommand is not the select command): defer or skip the probe.
  3. Add a test that starts a MOVE in a board, runs every polled verb, and asserts the MOVE is still active.

Filed from the Hydrogen thread. I will point Glenn here from #152.

3 Replies

Colby Knox · 11d ago

fusion-lane: confirmed, fix ready.

Cause. In 1.13.37, the add-in's get_app_state still runs Electron.run DISPLAY as its "is Electronics active" test. It also runs DebugCommands.ActiveWorkspace, and so does document_info. DISPLAY starts an EAGLE command, and starting a command in an electronics editor ends the user's command in progress, which matches the MOVE snapping back.

Who calls it on a cadence. get_app_state is the bridge's readiness round trip (rust/bridge/src/launch.rs, the probe behind fusion_readiness). It's also the statusVerb on most replies, the diagnostics and progress reads, and the waits in several verbs. So anything that polls readiness, such as ab's status, the dashboard or an AI thread waiting, cancelled the command each time.

Fix (add-in 1.0.29, shipping in the next insiders build).

  1. The polled reads now use the API only:
    • "is Electronics" is the active product's objectType (adsk::electron::…);
    • the workspace is ui.activeWorkspace (the same ids, e.g. BoardLayoutEnvironement). There are no text commands in get_app_state or document_info.
  2. get_app_state also reports userCommandActive, from ui.activeCommand, so callers can see a user command in progress and wait.
  3. A test (tests/test_polled_reads_run_no_commands.py) fails the build if a polled read ever runs a text command again.

Next is a live check on the test laptop: start a MOVE in a board, poll readiness and app state, and confirm the MOVE is still active. I'll post the result here. Users get the fix once Fusion restarts on add-in 1.0.29; fusion_restart_for_addin does that, saving open work first.

Colby Knox · 11d ago

The fix shipped in fusion-bridge 1.13.38 (insiders): add-in 1.0.29, with no text command in get_app_state or document_info (checked in the published zip). Next is the live check (a MOVE in progress survives readiness polling), then 1.13.38 or later goes public.

Colby Knox · 11d ago

Fixed and public: fusion-bridge 1.13.38 (add-in 1.0.29).

Checked live on the test laptop with the same sequence on each add-in: start an EAGLE MOVE on a board, then poll fusion_get_app_state and fusion_readiness the way readiness checks do.

  • Add-in 1.0.28 (before): Electron::Move was active, then gone after one poll. That's the bug as reported.
  • Add-in 1.0.29 (after): Electron::Move was still active after both polls, and get_app_state now reports userCommandActive: true.

Users get it when the bridge updates to 1.13.38 and Fusion restarts to load add-in 1.0.29. fusion_restart_for_addin does that, saving open work first. Glenn (hydrogen#152) should restart Fusion once after the bridge updates.

Colby Knox closed this · 11d ago

Log in to reply.