archetech / archon / 29584796074

90%

push

github

fix: report unfetchable asset bytes as an error, not as null (#738) (#739)

* fix: report unfetchable asset bytes as an error, not as null (#738)

get_asset_file and get_asset_image answered null when the gatekeeper could not
fetch an asset's CID, reporting an infrastructure failure as "this asset has no
data". The bytes exist; we just could not get them, and those are not the same
answer -- null looks like a result, while an isError is what a client actually
shows the user.

It also made behaviour depend on file size. The same broken asset answered null
below ARCHON_MCP_INLINE_LIMIT and, above it, a working-looking resource_link
that only failed when read. Both paths now report the same failure with the
same message.

keymaster already throws here -- getVaultItem raises "Failed to retrieve data
for item ... (CID: ...)" -- and resources/read does too since #734, so null was
the outlier rather than the house style. The message names the CID for the same
reason getVaultItem's does: it is what makes the failure diagnosable, and it is
already public in the DID document.

No resolve-first restructure was needed, contrary to what the issue proposed.
getImage already returns null only when the asset is not an image asset and the
file WITHOUT data when the fetch fails, so the two cases just needed separate
checks. get_asset_file was already structurally separated by #737, which checks
summary.cid before fetching -- only the wrong return value was left.

null now means one thing: the DID is not that kind of asset. The README said
"the asset carries no data", a state a file asset with a CID cannot reach.

Breaking: callers treating null as "empty asset" now see a tool error.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: avoid a nested template literal in the asset error

Lint failure, mine: sonarjs/no-nested-template-literals. The CID suffix was
built with a template literal inside the message's own template literal. Same
output,... (continued)

2979 of 3529 branches covered (84.41%)

Branch coverage included in aggregate %.

7 of 7 new or added lines in 2 files covered. (100.0%)

6173 of 6599 relevant lines covered (93.54%)

835.79 hits per line