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:
asyncrunScan() {thrownewError("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.
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().
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found while verifying the backend end to end:
romm_system action=scandoes not trigger a scan.That message comes from the client, not the server —
runScan()is a hard-codedthrow: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 servesPOST /api/tasks/scanwith aScanPayload(type,platforms,platform_fs_slugs,roms_ids,apis,launchbox_remote_enabled). Verified two ways against the running instance:/api/tasks/scanis present in the live 5.4.1 OpenAPI spec (226 paths), alongside/api/tasks/{task_id}and/api/tasks/statusfor polling;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, whereasfullre-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 shipsdist/plus.d.tsand nosrc/, and nopackage-lock.json, so patching.tswould mean pullingtypescriptin as a build dep for one function. Small, version-pinned (1.0.5), and deletable as soon as upstream restoresrunScan().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-serversinput and re-verifyscanthrough the gateway for real.