Answer 404 for section slugs that don't exist

[ssavutu]

The production error-rate panel has been sitting near 5% and is useless as an alerting signal, because the largest single contributor is not an error. Over 6h on Delta today: 720 400 GET /v1/sections/{section_slug}/articles and 326 400 GET /v1/subsections/{subsection_slug}/articles, roughly a thousand a day.

The slug is a path parameter on both routes, so a value that isn't in site_taxonomy is a missing resource, not a malformed request. It now returns 404.

Why it isn't a one-line status change

normalizeAndValidateArticleParams is shared with GET /v1/articles, where section_slug and subsection_slug are query filters the caller chose rather than the resource being addressed — 400 is correct there. So the validator returns two sentinels, errSectionNotFound and errSubsectionNotFound, and each handler passes the one whose slug came from its path:

writeError(w, articleParamsStatus(err, errSectionNotFound), err.Error())

GET /v1/sections/sports/articles?subsection_slug=bogus therefore still answers 400. So does subsection_slug does not belong to section_slug, which is a genuinely contradictory request.

The error message strings are unchanged, so response bodies are byte-identical and only the status code moves. That matters for the public site: getSectionArticles does if (!res.ok) return;, treating 400 and 404 the same, so this ships independently of anything on Scalene.

Where the volume actually comes from

Two client-side causes, both tracked on the Scalene board rather than fixed here:

• The Astro catch-all resolves a section page by trying /sections/ first and falling back to /subsections/, so every subsection page burns one failing request by design. Confirmed for politics, music, gaming, cooking, world.
• /sw.js 404s in production, falls through to the same catch-all, and gets looked up as a section — 126 of these in 90 minutes. The service worker isn't registering at all, which is a real bug independent of the metrics.

Three slugs 400 on both endpoints, meaning they're genuinely absent from site_taxonomy: podcasts, sjn-grant, tri-this-sweet-treat. Those need separate triage; this change makes them 404 instead of masking them as bad requests.

Deliberately out of scope

GET /v1/articles/{slug} returns 400 for values like index.xml. That slug really is syntactically invalid, and isValidCanonicalSlug has 25+ call sites that are mostly write endpoints where 400 is plainly right — not worth widening this diff for ~5 events per 6h.

Testing

go test ./... and go vet ./... clean. No existing test asserted 400 on these routes, so nothing needed loosening. Added coverage for both sentinels, the full status-mapping table, handler-level 404s, and the query-filter-stays-400 case. Swagger regenerated — additive 404 on these two routes only.

The taxonomy lookup can't be exercised locally (DB1's grants are host-scoped), so the handler tests run against the no-database fallback, which reaches the same sentinel. Real confirmation is the error-rate panel after deploy.

🤖 Generated with Claude Code