fix(api): make GET and DELETE /api/posts/:postId/taxonomy-tags reachable

[rkm1]

The defect

GET and DELETE /api/posts/:postId/taxonomy-tags have never worked over HTTP.

Both route patterns omitted the /api prefix that their POST sibling, the /api/posts/:postId/tags/suggestions route, and test/e2e/taxonomy-tagging.test.ts all use — while both handlers parse the id with pathname.split("/api/posts/")[1]. That is broken in two directions at once:

Request	What happens
/api/posts/:id/taxonomy-tags	matches no route → 404
/posts/:id/taxonomy-tags (the pattern's own path)	reaches the handler; split("/api/posts/")[1] is undefined; .split() on it throws a TypeError into the catch → 500

So reading a post's taxonomy tags and removing them are both dead. POST (adding tags) works — it has the prefix.

Why nothing caught it

This is the part worth reading.

Two unit files already exercised these handlers, and they passed. They found the route by testing the pattern against /posts/post-123/taxonomy-tags — the prefix-less pattern — and then handed the handler pathname: "/api/posts/post-123/taxonomy-tags".

The two halves cancel out. The lookup succeeds because the pattern lacks /api; the handler's parse succeeds because the pathname has it. Neither half corresponds to a real request, and together they describe a configuration the router cannot produce.

routes/posts.test.ts even carried this at every call site:

pathname: "/api/posts/post-123/taxonomy-tags", // Router may normalize to include /api

The mismatch was noticed, guessed at, and never checked. It does not normalize — regexToHonoPath translates the pattern as written and toHono passes the real url.pathname.

The e2e suite does call the real paths, and would have failed. It needs a live API_URL and doesn't run in the PR gate.

And this reaches a security fix. The V4(a) change that made this GET authenticate before its existence check — closing the anonymous cross-tenant post-existence oracle — is verified by posts-taxonomy-authz.test.ts. That file was green against a route no request could reach, and green because of the same cancelling mismatch. The ordering in the handler is correct; nothing was holding it down.

The fix

Add \/api to both patterns. Minimal, and it makes the patterns agree with their POST sibling, with both handlers' own parsing, and with the e2e contract.

Then remove the cancellation: every lookup and request URL in the three test files now uses the /api path, so if one half drifts again the tests fail instead of agreeing with each other.

New cover

routes-posts-extended.test.ts had no cases for either method, which is what let this survive. Added four:

• routability — findRoute tests each pattern against the path, so this asserts reachability rather than mere existence of a route object;
• the postId reaches the authorizer as "post-1", not undefined, plus an explicit assertion that no 500 is produced;
• GET answers 401 for an anonymous caller without consulting the post at all (mockDataRouterGetPost and mockCanReadPost both un-called) — pinning V4(a) with a test that can actually fail;
• DELETE's id reaches both DataRouter.getPost and removePostTaxonomyTags.

All four fail red against the old patterns: findRoute returns undefined, which is the 404 half of the defect reproduced as a test.

Verification

• vitest run in apps/api: 12264 passed, 0 failed (652 files, 6 skipped).
• tsc --build in apps/api (the lint script): clean.
• scripts/check-api-snapshot.mjs: both snapshots up to date. An /api prefix alone does not enter the OpenAPI snapshot — the POST sibling already has one and is absent from it.
• Two files failed on first run purely from the local sandbox blocking TCP binds (email-provider-scaleway, worker-runtime/health-shutdown); both pass with it off. Not related to this change.

Found while here, not fixed

DELETE still distinguishes 404 (no such post) from 403 (post exists, not yours) after a bare DataRouter.getPost. For any authenticated caller that discriminates post existence across tenants — the same family as the V4 residuals, narrower than the anonymous oracle since it needs a session. The consistent shape would be GET's uniform taxonomyDenyResponse, but turning a 403 into a 404 is an API behaviour change and a judgement call about the authz surface, so it belongs in the V4 residual work rather than smuggled in here.

🤖 Generated with Claude Code