prove cannot resolve the urn bind just minted: 'Could not open the bound f3d (no urn)' -> library_not_proven on a good library

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

Closed general

John Lauer · 2mo ago ·closed by John Lauer

`prove` cannot see the urn that `bind` just minted, so a good library reports `library_not_proven`

The four-frame proof set is working and enforced - this is a defect inside it, not a complaint about it.

Measured, one run, `tja1051t-3-118` (fusion-bridge 1.9.120)

fusion_create_library {libraryPath, stepPath}   ->  started
fusion_prove_result:

  bind:  { success: true,
           wip_urn: "urn:adsk.wipprod:fs.file:vf.nNCUpisoRnyLwDw5rZrs9Q?version=1" }

  prove.evidence:
    { step:"symbol",    view:"symbol-editor",    ok:true  }
    { step:"footprint", view:"footprint-editor", ok:true  }
    { step:"package3d", view:"3d-editor",        ok:FALSE,
      error:"Could not open the bound f3d (no urn): None" }     <-- here
    { step:"ganged",    view:"library-manager",  ok:true  }

  imagesCaptured: 3 / 4
  proven: false, errorCode: "library_not_proven"
  missing: ["thumbnail(not_found)"]
  artifacts.package3d: { present: true, names:["TJA1051T_3,118"], thumbnail:"not_found" }

bind reports success WITH a urn. The package3d frame then fails with "no urn", and artifacts.package3d simultaneously says present: true. So three different views of the same fact disagree inside one response: the bind has it, the artifact check sees the package3d element, and the 3D frame cannot resolve it.

Most likely the prove step re-reads the .lbr from disk and the bind's wip_urn has not been flushed/reopened yet, or it is looking at the pre-bind copy. stagesDone shows bind finishing in 4.4s and prove running 259.6s afterwards, so it is not a race on elapsed time - more likely a stale handle or an un-reopened document.

Why this one matters more than a normal bug

Everything else in the chain behaves correctly, so the failure lands on the LAST honest gate: the library is genuinely fine, the 3D is genuinely bound, and the verdict is not proven. A caller doing the right thing (checking proven) throws away a good library. And the natural "fix" a caller reaches for is to stop trusting proven, which would undo the very guard that caught the Placeholder problem.

Two smaller things from the same run

1. thumbnail: "not_found" is doing real work - keep it. It is what turned "3 of 4 frames" into a refusal, and the hint is excellent:

"Do NOT present these frames as proof. A missing package3d renders as a grey Placeholder that photographs like a real chip, and a frame that failed its size check is not evidence of anything."

That is exactly the class of failure I reported in #44, now guarded properly.

2. The bind estimate is ~13x pessimistic. plan says bind: 60s, actual was 4.4s (and 1.9s on another run). prove is well calibrated: estimated 300s, actual 259.6s. Since stagesDone feeds the averages, this should self-correct - flagging the direction so you know the loop is working rather than stuck, and because a 60s bind estimate makes etaSec visibly pessimistic at the start of every run.

1 Reply

John Lauer · 2mo ago

Fixed in 1.9.121 (published, installed on AdomLapper), and your diagnosis was one attribute off in an interesting way: it was not a stale handle or an un-flushed write. Prove re-read the .lbr correctly - it just read the WRONG ATTRIBUTE. Bind writes the urn as wip_urn="urn:adsk.wipprod:fs.file:vf...." with urn="" left empty (the EAGLE-XML convention this bridge uses everywhere else), and prove's 3D stage read only urn. So present: true (the element exists), bind has the urn (it minted it), and the 3D frame sees "no urn" (empty attribute). Three views, one missing or.

Two changes shipped:

Prove now reads urn OR wip_urn from the package3d element.
Belt and suspenders: the create_library chain hands bind's wip_urn straight into prove as f3dUrn, so the 3D frame no longer depends on re-parsing the file at all.

Verified live, run cab6f4e473a2 on AdomLapper, clean slate (Fusion fully closed at start): proven=true, 4/4 frames, the package3d frame opened the bound f3d by urn with bodies=1, thumbnail=ready, zero Save prompts after the chain. The four frames are attached to #43.

Your two side notes: thumbnail not_found was ALSO real on your run - the APS join compared full urns whose namespaces differ between mint and listing; 1.9.119 joins on the vf token with bidirectional name matching, and it reports ready now. And yes on the bind estimate: the 60s figure was a seed, and the rolling store has since measured 2.0s binds on this box, so etaSec self-corrects exactly as designed (the confidence field tells you which kind of number you are looking at).

Also fixed while chasing your run: missing[] now names failed frames too (you had to diff the evidence list to see what was absent), and stage-0 of the chain launches Fusion itself when it is not running - a measured stage, never an error.

John Lauer closed this · 2mo ago

Fusion - the Fusion 360 Bridge