APS search returns zero for a moving pincer model present in the matching native folder

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

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

Fusion bridge 1.10.11 (installed/running on Windows mesh peer), Adom Bridge CLI/host 2.1.96; Linux CLI build 541e1f0c-dirty, built 2026-09-10T15:32:39Z. Observed 2026-09-11, without restarting or changing bridge configuration.

fusion_aps_search {"query":"Pincer Moving Large","limit":20} returned count:0, results:[], scanned:{folders:16,hubs:1,projects:16}. The neighboring query Pincer Static Large found both its model and drawing.

The matching moving model exists in the same native cloud folder, 8-17-26 JLC CNC order, ID urn:adsk.wipprod:fs.folder:co.5UO0EOoUSRGE5xD4y0PcnQ. A read-only enumeration of that known folder returned V - Pincer Moving Large, lineage urn:adsk.wipprod:dm.lineage:ULqQblmWRLaz32BuoaYUjw, version1. Opening this exact lineage succeeded, and a source STEP export completed without modifying the document. The matching moving drawing also exists, lineage 1LfFLS0jQ_ej4YkYs2UNeg, version15.

Please investigate the search miss and return explicit completeness/indexing hints for zero results. A zero indexed result should not imply the file does not exist. A useful fallback hint would suggest inspecting a known related file's parent folder through the native Data API, preserving scope rather than starting an unrestricted cloud walk. The current catalog describes searching across the whole team hub but the response gives no caveat explaining this miss.

This is an observed search miss, not a claim about whether Autodesk indexing or bridge query/filtering is responsible. No duplicate open search-miss issue was found. Attached: zero-result response, native folder enumeration and successful source export. No foreground changes or source edits were used.

pincer-moving-large-aps-search.json

pincer-large-related-files.json

pincer-moving-large-native-export.json

1 Reply

John Lauer · 1mo ago

Shipped in 1.10.16 (insiders) and verified on ConfRoomROG with your exact query.

A zero from the server index no longer stands alone. fusion_aps_search now does what you suggested, automatically: shortened queries ("Pincer Moving", then "Pincer") run in parallel with the real one; when the full query comes back empty, the parent folders of those related index hits are listed through the Data API (folder contents, never the index) and names are matched directly. A two-level folder walk runs only when projectId scopes the search, so there is no unrestricted cloud walk.

Live result for {"query":"Pincer Moving Large","limit":10}: index count 0, data.fallback.count 5, including V - Pincer Moving Large (lineage ULqQblmWRLaz32BuoaYUjw, folder co.5UO0EOoUSRGE5xD4y0PcnQ, the ones in your report) and V - Pincer Moving Large Drawing (lineage 1LfFLS0jQ_ej4YkYs2UNeg), each with projectId, folderId and lineage, in 39 s. The reply also carries data.completeness (the index lags and tokenises, a zero does not prove absence) and a hint naming the sibling folder for fusion_aps_browse {projectId, folderId}.

Why it missed: the APS search index simply does not return that file for the query while its sibling "Static" file is returned; the bridge cannot fix the index, so it now routes around it.

John Lauer closed this · 1mo ago