Support the registry's new listing shape: full files, url/sha256 only on install - #110
Open
kmturley wants to merge 1 commit into
Open
Support the registry's new listing shape: full files, url/sha256 only on install#110kmturley wants to merge 1 commit into
kmturley wants to merge 1 commit into
Conversation
… on install The registry root/list endpoints (open-audio-stack-registry PR #933) now keep every file's compatibility fields (architectures, systems, contains, type, size, downloads, attested) at the summary tier, only omitting url/sha256 - unlike before, where the whole files array was absent. That means listing/filtering (search(), filter(), listPackages()'s architecture/system filter) can now work directly off Manager.sync()'s cached data with zero extra network calls; only install()/installDependency() - which need to actually download and hash-verify a file - fall back to fetchPackageVersion() for the full per-version payload. Fixes two real crash risks this shape uncovered along the way, since sync() now runs files-present-but-url-less data through code that previously always saw either full data or no files at all: - packageRecommendations() called pathGetExt(file.url) unconditionally per file, crashing on every sync() the moment a version had files without urls. - packageCompatibleFiles()'s format-exclusion check made the same call even when excludedFormats was an empty (but truthy) array, which is how every listing/filter call site passes it. Also updates packageIsVerified() to check url per-file rather than across the whole array, and adds PackageFileSummaryValidator (url/ sha256 optional) so Manager.sync() validates the new shape instead of rejecting every package over fields it never claimed to include.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Companion PR to open-audio-stack-registry#933, which changes the registry root and type-list endpoints (
GET /,/apps,/plugins,/presets,/projects) to keep every file's compatibility fields (architectures,systems,contains,type,size,downloads,attested) at the summary tier, only omittingurl/sha256per file (previously the wholefilesarray and older versions were considered for removal - this landed on the narrower, safer trim).Manager.sync()now validates that shape via a newPackageVersionSummaryValidator/PackageFileSummaryValidator(same as the full validators, buturl/sha256optional per file) instead of rejecting every package for a field it never claimed to include.search(),filter(),listPackages()'s architecture/system filter) now works directly offsync()'s cached data with zero extra network calls.install()/installDependency()- which need to actually download and hash-verify a file - fall back to a newfetchPackageVersion()/resolvePackageVersion()to get the full per-version payload (withurl/sha256) from the org/package/version endpoint. This is triggered per-file (whether every file already hasurl), not by whetherfilesexists.Bugs found and fixed along the way
Two real crash risks surfaced once
sync()started running files-present-but-url-less data through code that previously only ever saw either full data or nofilesat all:packageRecommendations()calledpathGetExt(file.url)unconditionally per file - this would crash on every singlesync()call the moment a version had files without urls. Now skips the url-derived checks (format recommendations) whenurlis absent; architecture/system tallying still runs.packageCompatibleFiles()'s format-exclusion check made the samepathGetExt(file.url)call even whenexcludedFormatswas an empty array ([]is truthy in JS) - which is how every listing/filter call site passes it. Now treats "can't determine format" as "don't exclude," rather than crashing.packageIsVerified()updated to checkurlper-file instead of gating on the wholefilesarray, so it degrades tofalse(not a crash) whenurlis missing on any file.Test plan
npm run format/npm run lint/npx tsc --noEmitnpm test(233/234 passing - the one failure,Install rolls back already-installed files..., is a pre-existingReferenceError: fileHelpers is not definedfrom the already-mergedrefactor/split-file-helpersPR [refactor] Split helpers/file.ts along its actual seams #108, unrelated to this change)sync()ingesting the summary shape without rejecting packages,resolvePackageVersion()fetching the full version only when needed,listPackages()'s architecture/system filter working on synced summary data with no extra fetch, and the two crash fixes above (packageRecommendations/packageCompatibleFilesno longer throw on url-less files)🤖 Generated with Claude Code