fusion_capture_library_views false-pass: marks a 3D/component view ok:true with NO chip in the screenshot when a build is mid-flight

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

From the Adom Bridge web-control library-import test campaign (fusion bridge 1.9.212). Related to #60 (library-import evidence bundle).

Bug

fusion_capture_library_views returns false-pass evidence when a 3D build is still in flight: it marks a view ok:true whose screenshot does NOT contain the expected content, and it captures the wrong editor for other views. The ok flag does not verify that the captured image actually shows the view it claims.

What happened (verified live on crr, 1.9.212)

fusion_build_library_3d is async - it returns immediately with status:"started" and the 3D build continues in the background. I called fusion_capture_library_views {"packages":["TJA1050"]} right after, while the build was still running. It returned:

captured: [
  { package:"TJA1050", view:"component",  ok:true,  path:".../fusion-TJA1050_component-...bmp" },
  { package:"TJA1050", view:"symbol",     ok:false, path:".../fusion-TJA1050_symbol-...bmp" },
  { package:"TJA1050", view:"footprint",  ok:false, path:".../fusion-TJA1050_footprint-...bmp" }
]

Then I looked at the actual pixels:

The component view, marked ok:true, contained NO 3D chip - just the footprint's pad outlines being built, plus >NAME/>VALUE. A pass flag on a screenshot with no component in it.
The symbol view (ok:false) actually showed the 3D-package editor (the SOP-8 body), not the schematic symbol - the wrong editor, mislabeled as "symbol".

So the build was holding the 3D-package editor on screen, and capture grabbed that editor for every view regardless of the label, marking one of them ok:true.

What it should do (and the proof the verbs are fine once sequenced)

After the async build actually finished - detectable only because the TJA1050_3d document flipped to isSaved:true in fusion_get_app_state.documents - a re-capture returned all three ok:true with the CORRECT content: the real schematic symbol (pins TXD/GND/VCC/RXD, S/CANH/CANL/VREF), the real 8-pad footprint, and the ganged component view (symbol + footprint + 3D thumbnail, Mapped check). So the verbs work; the defect is purely the missing guard + the unverified ok flag.

Asks

Guard against capturing mid-build. fusion_capture_library_views should detect an in-flight fusion_build_library_3d and either wait for it, or refuse with a clear errorCode (e.g. build_in_progress) - never silently capture the build editor and return ok:true.
ok must verify content, not just "a screenshot was saved." A component/3D view with no solid body (only pad outlines), or a symbol view showing the 3D editor, must be ok:false. A pass flag that doesn't look at what's in the image is exactly the false-pass class we keep hitting (placeholder-slab 3D, etc.).
fusion_build_library_3d needs a real completion signal. It is async with no way to poll "is the build done?" - fusion_get_app_state exposes no building/phase flag; I had to infer completion from a document's isSaved turning true. Give it a proper statusVerb/progress (this is the same gap #60 asks for: measured progress + a clear done signal so a caller can sequence capture correctly).

Once #1-#3 land, a caller can't accidentally get a "3D chip" screenshot with no chip in it.

2 Replies

John Lauer · 2mo ago

Both asks fixed in 1.9.215 (installed and hash-verified on crr and AdomLapper).

You found a false pass, which is the worst class of bug in an evidence pipeline: a refusal costs a retry, but evidence that lies gets believed. Both asks were correct and neither had a guard.

Ask 1: never capture mid-build

fusion_build_library_3d is async and nothing recorded that it was running, so capture had no way to know the build was holding the 3D-package editor on screen. _BUILD_IN_FLIGHT now marks a build for its duration (cleared in a finally, so a failed build cannot leave a permanent marker, with a one-hour ceiling as a second backstop). Capture refuses:

{ "errorCode": "build_in_progress",
  "error": "A 3D build is still running for C:/tmp/rayparts/tja1050.lbr - refusing to
            capture, because the build holds the 3D-package editor on screen and every
            view would show that editor instead of the view it is labelled with.",
  "buildsInFlight": [{"lbrPath": "...", "runningSec": 42}] }

The hint names your own completion signal (<part>_3d flipping to isSaved:true, or one <package3d wip_urn=...> per part in the bound .lbr), since you established it works. ignoreBuildInProgress: true opts out if you ever want a mid-build frame deliberately.

Ask 2: `ok` verifies content, not "a file was written"

Each capture now asks Fusion which editor was actually active at capture time, and a frame taken outside the Electronics Library editor is never a pass:

{ "view": "component", "ok": false,
  "errorCode": "wrong_editor_captured",
  "capturedInWorkspace": "Design",
  "error": "Captured while 'Design' was active, not the Electronics Library editor -
            the frame does not show the component view it is labelled with." }

That catches your exact case: the 3D-package editor captured and labelled "symbol".

Honest limit, stated plainly because you are relying on this flag. The bridge cannot read the captured pixels from here, so ok:true now means "the EDIT succeeded, a file was written, no dialog intervened, and Fusion was in the Electronics Library editor" — not "a chip is visible in the image." That is strictly stronger than before and it rules out the failure you filed, but it is not full content verification. A symbol view that renders empty for some other reason could still report ok:true. If you hit one, file it and I will add a pixel-level check.

The same release fixes Fusion's "Create new footprint 'X'?" modal, which library captures were raising and then dismissing after the fact. It froze the add-in's main thread while it sat there, so if any campaign verb read as "add-in not responding", that is a likely cause. Captures now resolve names against the .lbr offline and never issue an EDIT that would prompt.

John Lauer · 2mo ago

Closing with live verification at 1.9.341 (2026-09-01, crr): the false-pass class this issue named is now refused at several layers, all exercised today - the build_in_progress capture guard from 1.9.215 is in place (and survives a respawn), verdict:proven required real content on 13/13 parts across three runs, and the same honest-evidence doctrine caught two NEW false passes today in the managed-library verbs (push reporting success with its Create New Version dialog still open; pull ignoring its Up to Date dialog), both fixed by 1.9.332 with dialog-closure as the oracle instead of "no alerts".

John Lauer closed this · 2mo ago

Fusion - the Fusion 360 Bridge