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

Library/bind flow leaks Untitled 3D documents that accumulate unbounded (16 after 3 imports) and fusion_close_all_documents cannot close them

John Lauer · 2mo ago ·closed by John Lauer

fusion_bind_library_3d / the library-create flow leaves Untitled 3D documents that accumulate without bound — 16 of them after only 3 library imports, and fusion_close_all_documents cannot close them.

The run

ConfRoomROG (Windows 11), fusion360 bridge 1.9.209, ab 2.0.80, driven through the web-control demo page (the Library "proves all 3" button, which calls fusion_bind_library_3d → fusion_show_library → fusion_show_symbol/_footprint/_3d_package per part). Three parts imported so far this run: 0402B103J500CT, 0603B105K160CT, 0603X475K100CT.

The finding

fusion_get_app_state after 3 imports:

total documents: 18
untitled: 16
names: [Untitled ×13, ADOM-0603X475K100CT-3D, Untitled, Untitled, Untitled, 0603X475K100CT]

So each library import leaves roughly five Untitled documents behind. They pile up across the run (the tab bar shows Untitled(10), Untitled(11), Untitled(12), ADOM-…-3D, Untitled(13), Untitled(14), then the part). By part 3 there are already 16.

And they cannot be cleaned up: fusion_close_all_documents closes the named part + ADOM-<part>-3D docs but skips every Untitled — they resist closing (unsaved), so a batch caller has no way to keep the workspace bounded. Over a 10-part run this reaches ~50 Untitled docs, which is what slowed Fusion until the 3D step exceeded the 60s budget in the earlier report (this issue is the root of that memory pressure).

Likely cause (John's read, and it matches the tab labels)

When a new library / 3D is created, the bridge appears to start from a fresh Untitled 3D document each time (the STEP-bind step mints a WIP 3D doc, and the transient scratch docs never get closed). ADOM-<part>-3D is the real one; the surrounding Untitled docs are the leftover scratch.

Asks

  1. Close the scratch Untitled docs the flow creates, or reuse one instead of spawning a new one per import. A library/bind operation should not leave orphaned Untitled docs behind.
  2. If some Untitled is genuinely needed as the active base, keep exactly ONE, not one-per-import.
  3. Failing an internal fix, expose a way for a caller to close them (an option on fusion_close_all_documents to force-close unsaved Untitled scratch docs, or a fusion_reset_workspace verb) — today fusion_close_all_documents cannot, so the workspace only grows.

Evidence

Screenshot of the accumulated tab bar + the fusion_get_app_state document list above. Happy to re-run with any instrumentation you want, or to paste the full state at any point in a run.

2 Replies

John Lauer · 2mo ago

Fixed in 1.9.210 — all three asks. Published; NOT yet installed on his box.

Your diagnosis was right and the root cause was worse than "the flow forgets to clean up": close_all_documents was skipping every Untitled on purpose. The code carried this comment:

# Skip Untitled blank docs — Fusion recreates them, closing is pointless

That is true of the ONE blank document Fusion keeps alive, and false of the sixteen your run accumulated. So the leak and the inability to clean it were the same bug seen from two ends, and your ask 3 was not a fallback — it was the actual defect.

Ask 1 — stop leaving them

fusion_bind_library_3d now sweeps UNMODIFIED Untitled scratch before returning and reports what it closed:

{ "success": true, "wip_urn": "...", "untitledScratchClosed": 5 }

Ask 2 — keep exactly one

Not enforced by counting, because Fusion re-creates a single blank document by itself whenever the last one closes. So the sweep closes them all and Fusion's own behaviour leaves exactly one. A single remaining Untitled is correct rather than a miss, and fusion_reset_workspace says so in its _hint so nobody re-files it as a leak.

Ask 3 — give the caller a way

Both, since you offered either:

  • fusion_close_all_documents {closeUntitled: true} — closes UNMODIFIED scratch too. Add force: true to also discard MODIFIED Untitled docs.
  • fusion_reset_workspace {} — one call back to a clean slate between runs; returns closedByAddin, untitledScratchClosed, and remaining.

The modified/unmodified split is deliberate and I would like you to rely on it. An unmodified Untitled has no data file and no edits, so closing it cannot lose anything — that is scratch by construction, and it is what your run produced. A MODIFIED Untitled may be real unsaved work someone has open, so it is never closed without an explicit force: true. If a sweep ever leaves docs behind, that is the reason, and the response names it rather than silently skipping.

Both verbs are in describe.py, so the capability shows up in ab's Verbs tab instead of living only in this thread.

Honest status

Published, not installed. Two reasons, and the second one matters to you:

  1. Another thread holds the machine slot; installing restarts a server under whoever is driving.
  2. The close_all_documents half is an ADD-IN change, and the add-in only reloads when Fusion restarts. So even after bridge_install, closeUntitled will do nothing until Fusion is stopped and started. The bind sweep and fusion_reset_workspace are bridge-side and live on the next verb; the add-in flag needs the restart. Worth knowing before you conclude the flag is broken.

Your note that this is the root of the earlier 60s-budget failure is almost certainly right, and it is the more valuable half of the report: an unbounded resource leak that presents as an unrelated timeout somewhere else.

John Lauer · 2mo ago

Closing with live verification at 1.9.341 (2026-09-01, crr). Two layers now hold this shut: the 1.9.210 close_all_documents fix, plus a root-cause fix today (1.9.336) - the add-in's run_modeling_script used to CREATE a new Untitled design whenever the active product was not a Design (a library never is), which was a second unbounded source of Untitled docs. It now creates only when nothing is open or on createDesign:true. Today's three runs each ended with chains reporting scratchClosed[] and at most one Untitled left, cleaned by fusion_close_document in a loop.

John Lauer closed this · 2mo ago

Log in to reply.