romm-mcp: restore library scans via POST /api/tasks/scan #20

Merged
hermes-agent merged 1 commits from fix/romm-scan-endpoint into main 2026-11-02 13:56:17 +01:00
Collaborator

Found while verifying the backend end to end: romm_system action=scan does not trigger a scan.

⚠️ Scan endpoint removed in RomM 5.0. Use the RomM web UI to trigger library scans.

That message comes from the client, not the server — runScan() is a hard-coded throw:

async runScan() {
  throw new Error("Scan endpoint removed in RomM 5.0. Use the RomM web UI to trigger library scans.");
}

The note is stale. RomM 5.0 removed POST /api/tasks/run, which is what the comment above the stub refers to. RomM 5.4 serves POST /api/tasks/scan with a ScanPayload (type, platforms, platform_fs_slugs, roms_ids, apis, launchbox_remote_enabled). Verified two ways against the running instance:

  • /api/tasks/scan is present in the live 5.4.1 OpenAPI spec (226 paths), alongside /api/tasks/{task_id} and /api/tasks/status for polling;
  • after this patch, a call with a deliberately bad key returns 401 Not authenticated [POST /api/tasks/scan] — the request reaches the endpoint. Before the patch it never left the process.

Patch: runScan() now POSTs {"type": "quick"}. Quick is the right default: it indexes new/changed files, whereas full re-hashes the entire library (229 GB here). romm_manage_collections-style argument plumbing is untouched.

It patches dist/client.js, which is not ideal but is the only option: the npm tarball ships dist/ plus .d.ts and no src/, and no package-lock.json, so patching .ts would mean pulling typescript in as a build dep for one function. Small, version-pinned (1.0.5), and deletable as soon as upstream restores runScan().

Not changed: runMetadataScan() still throws — I couldn't find a metadata-only task endpoint in the 5.4.1 spec, and guessing one would be worse than leaving it explicit.

Builds; binary starts; the patched code path verified as above. Once merged I'll bump the config mcp-servers input and re-verify scan through the gateway for real.

Found while verifying the backend end to end: `romm_system action=scan` does **not** trigger a scan. ``` ⚠️ Scan endpoint removed in RomM 5.0. Use the RomM web UI to trigger library scans. ``` That message comes from the client, not the server — `runScan()` is a hard-coded `throw`: ```ts async runScan() { throw new Error("Scan endpoint removed in RomM 5.0. Use the RomM web UI to trigger library scans."); } ``` **The note is stale.** RomM 5.0 removed `POST /api/tasks/run`, which is what the comment above the stub refers to. RomM 5.4 serves `POST /api/tasks/scan` with a `ScanPayload` (`type`, `platforms`, `platform_fs_slugs`, `roms_ids`, `apis`, `launchbox_remote_enabled`). Verified two ways against the running instance: - `/api/tasks/scan` is present in the live 5.4.1 OpenAPI spec (226 paths), alongside `/api/tasks/{task_id}` and `/api/tasks/status` for polling; - after this patch, a call with a deliberately bad key returns **`401 Not authenticated [POST /api/tasks/scan]`** — the request reaches the endpoint. Before the patch it never left the process. **Patch:** `runScan()` now POSTs `{"type": "quick"}`. Quick is the right default: it indexes new/changed files, whereas `full` re-hashes the entire library (229 GB here). `romm_manage_collections`-style argument plumbing is untouched. It patches `dist/client.js`, which is not ideal but is the only option: the npm tarball ships `dist/` plus `.d.ts` and no `src/`, and no `package-lock.json`, so patching `.ts` would mean pulling `typescript` in as a build dep for one function. Small, version-pinned (1.0.5), and deletable as soon as upstream restores `runScan()`. **Not changed:** `runMetadataScan()` still throws — I couldn't find a metadata-only task endpoint in the 5.4.1 spec, and guessing one would be worse than leaving it explicit. Builds; binary starts; the patched code path verified as above. Once merged I'll bump the config `mcp-servers` input and re-verify `scan` through the gateway for real.
hermes-agent added 1 commit 2026-11-02 13:51:04 +01:00
romm-mcp: restore library scans via POST /api/tasks/scan
NixOS Configuration CI / Nix Flake Check (pull_request) Successful in 25s
106bf1014e
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().
hermes-agent merged commit 78b0a621fd into main 2026-11-02 13:56:17 +01:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: luis/mcp-servers#20