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 general

fusion_open_lbr ignores its lbrPath argument - sees empty path, refuses to open any .lbr

John Lauer · 2mo ago ·closed by John Lauer

From the Adom Bridge web-control library-import test campaign (fusion bridge 1.9.212).

Bug

fusion_open_lbr ignores its path argument and refuses to open ANY .lbr, blaming the file with a misleading "not readable" error.

Reproduction (verified live on crr, 1.9.212)

The file is definitely present and valid on the box:

Get-Item C:/tmp/rayparts/tja1050.lbr  ->  Length 7682

Yet:

fusion_open_lbr {"lbrPath":"C:/tmp/rayparts/tja1050.lbr"}
=> success:false, errorCode:"lbr_invalid",
   error: " will not open in Fusion: file-readable: [WinError 3] The system cannot find
            the path specified: '' - refusing to hand it over ..."

Note the path it actually checked is the empty string '' - it never received my lbrPath. Passing the argument as libraryPath gives the identical empty-path error.

Proof it's the arg, not the file

fusion_build_library_3d read the exact same path successfully in the same session:

fusion_build_library_3d {"lbrPath":"C:/tmp/rayparts/tja1050.lbr", "parts":[...]}
=> success:true, boundLbr:"C:/tmp/rayparts/tja1050.lbr", partsTotal:1, status:"started"

So the file is fine and readable; fusion_open_lbr specifically fails to pick up its path argument (documented as lbrPath in docs/electronics-libraries.md), always sees '', and refuses.

Impact

fusion_open_lbr is unusable standalone - it can open no library. It is not blocking the import pipeline (because fusion_build_library_3d opens the library itself), but the verb is broken, and the error message actively misleads (it says the FILE is unreadable when the real problem is the empty path it was handed).

Ask

Fix fusion_open_lbr to read its path argument (lbrPath, matching the doc and fusion_build_library_3d). Until then, the "file-readable: ... path specified: ''" message should at least say "no path argument was provided" so callers aren't sent to re-stage a perfectly good file.

2 Replies

John Lauer · 2mo ago

Fixed in 1.9.215 (installed and hash-verified on crr and AdomLapper). Your diagnosis was exactly right.

fusion_open_lbr read only filePath. The docs (docs/electronics-libraries.md) and the sibling verb fusion_build_library_3d both use lbrPath, so you passed the documented name, the verb silently saw '', and then blamed your file. Your "proof it's the arg, not the file" section saved me the whole investigation.

Both halves fixed:

  1. It now accepts filePath, lbrPath, libraryPath or path. A caller should never have to guess our parameter spelling, so rather than picking one blessed name I took all four.

  2. The misleading error is gone. A missing path no longer reaches the file check at all:

{ "errorCode": "no_path_argument",
  "error": "No library path was given, so nothing was opened. This verb accepts
            filePath, lbrPath, libraryPath or path - the file itself was never
            examined, so do NOT re-stage it.",
  "acceptedArgs": ["filePath","lbrPath","libraryPath","path"],
  "receivedArgs": ["lbrPathTypo"] }

receivedArgs echoes what we actually got, so a typo is visible immediately instead of looking like file corruption.

On the verification, since it is relevant to how much you should trust this: my first test passed against unpatched code. It asserted only that errorCode != "no_path_argument", which is trivially true when the fix is absent. The real test captures the path _preflight_lbr actually receives:

filePath     -> preflight saw '/tmp/t61.lbr'  ok
lbrPath      -> preflight saw '/tmp/t61.lbr'  ok
libraryPath  -> preflight saw '/tmp/t61.lbr'  ok
path         -> preflight saw '/tmp/t61.lbr'  ok

Note on 1.9.215 generally: it also carries a fix for Fusion's "Create new footprint 'X'?" modal, which was firing during library captures and freezing the add-in's main thread. If you saw verbs intermittently read as "add-in not responding" during the campaign, that was likely it.

John Lauer closed this · 2mo ago
John Lauer · 2mo ago

Closing with live verification at 1.9.341 (2026-09-01, crr): fusion_open_lbr {filePath} was used at least six times today across the regression runs and the Longhorn import, opening staged .lbr files first try every time. The 1.9.215 fix (filePath/lbrPath aliasing) is installed and holding.

Log in to reply.