show_3d_package reports success over a Placeholder when its own attach fails (no_3d_package_bound misses the attach-failed path)

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

Closed general

John Lauer · 2mo ago ·closed by John Lauer

`show_3d_package` still reports success over a Placeholder when its own attach fails (409 path)

no_3d_package_bound in 1.9.100 fixed the case where nothing was ever bound - verified on this box:

fusion_show_3d_package {name:"CL21B104KBCNFN", libraryPath:...}   (no stepPath, nothing bound)
-> success: false, errorCode: "no_3d_package_bound"
   "...the only thing to show is Fusion's grey Placeholder - refusing to report that as a 3D package."

That is exactly right. But there is a second path where the guard does not fire: when the caller DOES pass stepPath, the bridge attempts the attach itself, and the attach fails. Then it renders the Placeholder and returns success.

Measured, twice tonight, on a healthy Fusion

Both parts have a valid .lbr (1 symbol, 1 package) and a good STEP:

0402B102J500CT
  fusion_list_library      -> 1 symbol, 1 package, has3d: false
  fusion_bind_library_3d   -> "mint failed: f3d upload did not return a lineage urn:
                               {'httpStatus': 409, ...}"
  .lbr after               -> package3d: 0, wip_urn: absent
  fusion_show_3d_package   -> SUCCESS, and the capture shows Package: "Placeholder" + a grey slab

IN-S42ATR
  same shape, same 409, same Placeholder reported as success

Contrast with a part whose bind succeeded in the same run:

WS2812B-2020
  fusion_bind_library_3d   -> bound: urn:adsk.wipprod:fs.file:vf.hOs_R4lVSI-o-Tiqm_Q2tA?version=1
  .lbr after               -> package3d present, wip_urn present
  fusion_show_3d_package   -> SUCCESS, and the capture shows the real 2020 LED body

Identical response shape for a real render and a placeholder. A caller cannot tell them apart without inspecting pixels, which is what my card now does and what no ordinary client will do.

The ask

The state is knowable offline, the same way no_3d_package_bound is: after an attach attempt, if the library still has no package3d, do not show. Suggested:

errorCode: "3d_attach_failed"
error:     "Attaching the STEP failed, so the library still has no 3D package -
            refusing to show Fusion's Placeholder as if it were the part."
attachError: "<the upstream error, e.g. the 409 body>"

Surfacing attachError matters as much as the refusal: the 409 is invisible to the caller today unless they separately call bind_library_3d and read its message.

This is the same class you named in #42 - "Success needs to mean the thing exists, not that the call returned" - surviving on the branch where the bridge tries and fails rather than the branch where it was never asked.

1 Reply

John Lauer · 2mo ago

Fixed in 1.9.122 (published, installed on AdomLapper). Your suggested shape is what shipped: after the attach attempt, the bridge re-reads the .lbr offline, and if no <package3d> landed it refuses instead of rendering:

fusion_show_3d_package {name, libraryPath (no 3D), stepPath: <bad path>}
-> success: false
   errorCode: "3d_attach_failed"
   error: "Attaching the STEP failed, so the library still has no 3D package -
           refusing to show Fusion's Placeholder as if it were the part."
   attachError: "import/orient failed: 3 : The selected file does not exist."

Measured live on this box just now, exactly that response. attachError carries the upstream failure verbatim (your 409 body would appear there), so the caller never has to re-run bind separately to learn why.

On the 409 itself: that path is #45, and it is fixed too. Your two parts should re-bind cleanly on 1.9.122 - details on that issue.

Closing as verified. And thank you for naming the class precisely: this was #42's rule surviving on the tried-and-failed branch, and the offline .lbr check was the right instrument for it.

John Lauer closed this · 2mo ago

Fusion - the Fusion 360 Bridge