romm_system action=scan threw client-side:
Scan endpoint removed in RomM 5.0. Use the RomM web UI to trigger library scans.
That note is stale. The comment above the stub says RomM 5.0 removed POST
/api/tasks/run -- true -- but 5.4 serves POST /api/tasks/scan with a ScanPayload
(type, platforms, platform_fs_slugs, roms_ids, apis). Verified against the running
instance: /api/tasks/scan is in the 5.4.1 OpenAPI (226 paths), and a call with a
bad key answers 401 from that exact endpoint rather than 404.
So the stub was blocking a working endpoint, and scans still needed a human in the
UI. Patch restores runScan() defaulting to type=quick, which indexes new and
changed files without re-hashing the whole library (a full scan hashes 229 GB).
The patch targets dist/client.js: the npm tarball ships only dist/ plus a .d.ts, so
there is no .ts to patch without dragging in typescript. Keep it small and delete
it when upstream restores runScan().
Both come from the build, and both were non-obvious:
- fetchzip hashes the *unpacked* tree, not the .tgz bytes, so a hash computed
from the published tarball does not match; the derivation reports the NAR hash
of the extracted contents instead.
- npmDepsHash only exists once npm has materialised the dependency tree from the
committed lockfile.
Verified with nix build .#romm-mcp: the derivation builds and ./result/bin/romm-mcp
starts and prints 'RomM MCP server running on stdio'.
RomM MCP server: browse, search and administrate a self-hosted ROM library,
including triggering library scans (POST /api/tasks/scan), which RomM 5.x only
exposes through its API.
Upstream ships no package-lock.json, so the lock committed here is generated from
the published 1.0.5 tarball (npm install --package-lock-only --ignore-scripts),
pinning exactly the tree that shipped with that version. dist/ is prebuilt in the
tarball, hence dontNpmBuild.
npmDepsHash is a placeholder: it can only be derived from the lockfile by a build,
so CI (nix flake check, which builds every package) reports the real value.