fix(items): read the id strictly, and stop the error test needing a route that does not (#307)

Item 5. GET /api/items/:id was the last route reading its id with a bare Number(), so an unreadable id reached Postgres and came back to the caller as a 500 for an item that cannot exist. It answers 404 now, like every other id-taking route since #207.

It could not be fixed on its own, which is why it stayed. errorHandling.integration.test.ts used this route's looseness as its way of making a handler reject: tightening the parse would have left that test green while removing the thing it tests. So the test now fails a database call directly, with a spy on pool.query against a route that makes one. That is the failure the error middleware actually exists for, and it does not depend on any route declining to validate — the previous comment's own conclusion, that moving the trigger to cart.ts would only move the wart.

Two things fixed along the way that the issue asked about but that switching to readId would not have delivered on its own.

readId was not as strict as its name suggests. Number reads 5.0, 1e2, 0x10 and +5 as 5, 100, 16 and 5 — every one a positive integer, so every check readId made passed and the route fetched a real row for a URL nobody wrote. /items/5.0 answered with item 5. This never raised an error and so never announced itself; the issue noticed it only because #308 converted the comparison to a real integer. An id is a string of digits, so it is matched against digits before being parsed.

readId is also now bounded at the top of a 32-bit serial. Above that Postgres raises 22003 rather than returning nothing, which is the same wrong answer to the caller as the 22P02 the function was written to prevent — a 500 for an id that identifies nothing.

The leak assertion was passing for the wrong reason. It checks the response does not contain "syntax" or "items", and the error it was checking against happened to contain both only by accident of which route was used. The injected failure now contains both words deliberately, and the whole message is asserted against as well, so a future error format cannot slip through by wording itself differently.

Verified: tsc clean, lint 0 errors with no new warnings, 485 unit tests passing across 33 suites — seven of them new, covering the inputs above. The integration suite cannot run on this machine, so whether the rewritten error test passes is for CI to say.

Item 4, coverage, is not closed by this and cannot be closed yet: the SonarQube scan step has been skipped on every recent run because it is gated on the earlier steps succeeding, and those steps were failing. The dashboard is therefore stale. Reported on the issue rather than guessed at.

Refs #307

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/src/routes/items.ts

@@ -1,6 +1,7 @@
 import { Router, Request, Response } from 'express';
 import { asyncRoute } from '../asyncRoute';
 import { publicItemQuery, PublicItemRow, ItemContext } from '../itemSelect';
+import { readId } from '../utils';
 import {
   parseItemFilters,
   itemFilterExpressions,
@@ -93,16 +94,20 @@ router.get('/', asyncRoute(async (req: Request, res: Response) => {
 }));
 
 router.get('/:id', asyncRoute(async (req: Request, res: Response) => {
-  // Number() rather than readId(), and that is deliberate rather than an
-  // oversight. readId would be stricter and would match every other id-taking
-  // route (#207) — but errorHandling.integration.test.ts drives this exact
-  // route with a non-numeric id to prove that asyncRoute plus the error
-  // middleware answer 500 rather than leaving the request hanging, and a
-  // stricter parse here would leave that test green while removing the thing
-  // it tests. Switching this over means giving that test another trigger in
-  // the same change. See #307.
+  // readId, like every other id-taking route since #207. This was the last one
+  // reading its id with a bare Number(), which meant an unreadable id reached
+  // Postgres and came back to the caller as a 500 for an item that cannot
+  // exist. 404 is what "/items/abc" actually means.
+  //
+  // It was left on Number() because errorHandling.integration.test.ts used this
+  // route's looseness as its way of making a handler reject. That test now
+  // fails a database call directly instead, so it no longer depends on a route
+  // declining to validate — which is what allowed this to be fixed (#307).
+  const id = readId(req.params.id);
+  if (id === null) return res.status(404).json({ error: 'not found' });
+
   const rows = await publicItemQuery()
-    .where('i.id', '=', Number(req.params.id))
+    .where('i.id', '=', id)
     .where((eb) => notPending(eb))
     .execute();
   if (!rows.length) return res.status(404).json({ error: 'not found' });