Re-minting an already-uploaded part returns HTTP 409, so a re-run can never rebuild its 3D

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

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Re-binding an already-minted part fails with HTTP 409, so a repeatable run can never rebuild its 3D

What happens

fusion_bind_library_3d mints the STEP as a cloud f3d and injects the wip_urn. Run it a second time for the same part - after the local .lbr has been replaced with a fresh copy - and Autodesk rejects the upload:

mint failed: f3d upload did not return a lineage urn:
{'httpStatus': 409, 'body': {'jsonapi': {'version': '1.0'},
 'errors': [{'id': 'de4ad58d-3a4b-427f-8e30-741dd5...'}]}}

Measured on two parts tonight (0402B102J500CT, IN-S42ATR), both of which bound successfully in an earlier run. The .lbr afterwards has package3d: 0 and no wip_urn, so everything downstream sees an unbound library.

Why this is the normal case, not an edge case

Any repeatable test re-stages its inputs. My matrix fetches each part's .lbr and .step fresh from the wiki for every run, which is the correct thing to do - it tests what a real user gets from the part page. But a freshly downloaded .lbr has no wip_urn, while Autodesk's cloud still holds the lineage from the previous run. The bridge then tries to upload a file that already exists, and gets a 409.

So the second and every subsequent run of the same part cannot produce a 3D, on a machine where the first run worked. That is a bad property for a demo, a test suite, or a user who re-imports a part they imported last week.

What I think the fix looks like

The cloud already has exactly the object we want. Rather than uploading again:

Look up the existing lineage first and reuse its urn - inject the known wip_urn into the fresh .lbr and report alreadyMinted: true. This is the cheap, common path.
Or supersede: upload as a new VERSION of the existing lineage rather than a new file, which is what ?version=1 in the urn implies is possible.
At minimum, report it usefully: errorCode: "already_minted" with the existing urn if you can discover it, so the caller can inject it themselves rather than parsing a 409 body.

The related ask in #42 covers the reporting half (alreadyBound: true with the existing wip_urn); this issue is the case where the local file no longer knows about a binding that still exists in the cloud.

Context

WS2812B-2020 in the same run bound cleanly and rendered the real 2020 LED body, so the mint path itself is in good shape - this is specifically about the second time.

1 Reply

John Lauer · 2mo ago

Fixed and verified on 1.9.122 with your exact scenario: a freshly staged .lbr (no package3d, no wip_urn) for a part whose f3d already lives in the cloud from an earlier run.

fusion_create_library {libraryPath: CR0603-fresh.lbr, stepPath: ...}   (run e479bc6894ef)
  bind:  35.1s, success: true,
         wip_urn: "urn:adsk.wipprod:fs.file:vf.GbB89VT-SnGnkFo3V5B7_A?version=1"
  chain: proven=true, 4/4 frames, thumbnail ready

That wip urn is the SAME lineage the original run minted - the bridge found the existing cloud object and reused it instead of failing on the duplicate upload. Your first suggested fix is the implemented one: on a 409 the bridge looks the existing item up in the upload folder's listing, takes its dm.lineage id (which is exactly what the vf. wip form is built from), injects it into the fresh .lbr, and proceeds. So run N of the same part behaves like run 1, which is the property your matrix needs.

One honest caveat: reuse matches on the f3d file name in the AI workspace folder (ADOM-<part>-3D), so a part renamed between runs would mint a second lineage rather than reuse - acceptable, since a rename is a new artifact by contract.

Also shipped in 1.9.122, found while chasing this: the hung-host gate could taskkill a HEALTHY Fusion mid-bind (a heavy STEP import starves the very probes the gate reads, and IsHungAppWindow reports a busy main thread as hung). If your matrix ever saw Fusion vanish mid-run with no crash dialog, that was it. A kill now requires 180s of persistence plus a refused 20s probe; anything less reports fusion_addin_busy and tells the caller to wait.

Closing as verified.

John Lauer closed this · 2mo ago