mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-11 01:32:22 +03:00
c7e20e95de
* fix(api): validate request bodies with Zod in 4 routes — restores the t06 gate The release-green verdict (#9737) lists check:route-validation:t06 as a HARD failure and it is STILL red on the current tip: four routes call request.json() and hand-roll `typeof x === "string"` checks instead of using Zod, which Hard Rule #7 requires and the gate enforces (it scans source and has no allowlist). - src/app/api/plugins/marketplace/install (#9445): InstallBodySchema; the 400 'Missing or invalid name field' response is preserved verbatim. - src/app/api/services/dario/admin/accounts (#8523): DeleteAccountBodySchema for the optional { alias } DELETE body; query-param path untouched. - src/app/api/services/dario/admin/login-start (#8523): LoginStartBodySchema; trimming now happens in the schema, so the forward body is unchanged. - src/app/api/services/dario/admin/import-from-omniroute (#8523): ImportBodySchema for connectionId/alias; invalid shapes fall back to the same 'connectionId is required' 400 as before. All four keep their exact status codes and messages — this is a validation mechanism swap, not a contract change (plugins route suite still 33/33). Adds tests/unit/route-body-validation-t06.test.ts, which runs the gate's own rule inside the unit suite so the next such route fails on ITS OWN PR instead of surfacing weeks later in a base-red sweep. Guard verified by mutation: renaming .safeParse( in one route makes it fail (1 fail), restored from a pre-probe copy. Gates: route-validation:t06, file-size, test-discovery, mutation-test-coverage, dead-code exit 0; typecheck:core clean; eslint clean. Refs #9737 * fix(memory): register the sqlite backend on the /api/memory/[id] route — every handler 500'd GET/PUT/DELETE /api/memory/[id] threw `Primary backend "sqlite" not registered` and returned 500. #8752 (MemoryBackend provider pattern) wired the route to `@/lib/memory/manager` directly, but the registry is populated by an import-time side effect in the module INDEX (src/lib/memory/index.ts:23, `memoryManager.register(sqliteBackend)`). Importing the bare manager gives an empty registry. In production the failure is order-dependent, which is why it went unnoticed: if /api/memory (which imports the index) is hit first in the same process, the singleton is already populated and [id] works. Reached first — the common case for a client that edits a known memory id — every request 500s. The sibling route is the only other consumer and already imports the index; this was the lone direct-manager import in src/. - Fix: import from `@/lib/memory` (index) with a comment stating WHY the indirection matters, so the next refactor does not simplify it back. - Guard: tests/integration/memory-route-put.test.ts already covered this and was failing 2/5 on the base (it only surfaced now because the integration suite runs on the release-PR CI, not per-PR). Now 5/5. Also fixes a test-isolation defect in the same run: tests/integration/combo-matrix/context-relay-codex.test.ts reused one combo name across both tests, and the control failed with `UNIQUE constraint failed: combos.name` — resetStorage() unlinks the DB file but the previous better-sqlite3 handle keeps writing to the same inode. Gave the control its own combo name and parameterized the request builder; the assertion is unchanged (it never depended on the name). 2/2. Integration suite on this tip: 936 tests, 32m19s — under the 40min ceiling the old verdict reported as exceeded (#9737 item 6), which the migration-135 collision was causing. Refs #9737 --------- Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>