Public: anyone can read this; the crew can change it.
The OpenAPI waves reads list the query parameters their handlers read, and a test compares them #11370
Check · Review · Land · Live done — Landed and live in production.
Neither waves handler reads a query parameter, so the routes now say they take none and the test checks that.
shipped production is serving it deploy abf00b0
Neither waves handler reads a query parameter, so the routes now say they take none and the test checks that.
- What changed: both waves route summaries start with "Takes no query parameters". The list summary adds that it isn't paged, since
next_cursoris always null. Neither route gets aqueryentry. - Test: the waves-list test in
test/openapi-oa-waves.test.tsalready compared the route's parameters to the handler's reads. It now also asserts that the handler reads none. A new test does the same forGET …/waves/{version}and checks the list summary says it takes none. If either handler later readssearchParams.get("x")without the route listingx, the comparison fails. - Not done: no handler behaviour changed, and I added no pagination parameters.
- Checks:
test/openapi-oa-waves.test.tspasses (5 tests), andtscandscripts/gate.tsreport nothing. I did not run the rest of the suite; the forge runs the full check on push.
To try it, open /api/v1/openapi.json and look at the two waves paths.
🤖 Generated with Claude Code
Both handlers do read no query parameter (checked src/http/api.ts waves list and waves/:version), and the summaries say so. One fix first: the new test for waves/{version} asserts the wording on the LIST path (doc.paths[${R}/waves]), so the summary this pull adds to waves/{version} is untested; deleting it keeps the suite green. Assert on doc.paths[${R}/waves/{version}].get, and assert the list's own wording too (not only 'no query parameters' but the not-paged note, or drop that claim from the summary). Also: the // Keep a thought exactly as typed end marker for slicing the handler is an unrelated comment two routes away; it will break or silently widen the slice when that code moves. Slice to the next router.add( instead. Smaller: the test title '(none)' is noise.
I've made all three changes @juniper asked for, and pushed them to the same branch.
- Wrong path: a new test, "the waves summaries say they take no query parameters", reads the summary of each route under test. For the list it checks "Takes no query parameters (the list is not paged: next_cursor is always null)". For
waves/{version}it checks "Takes no query parameters". Deleting that wording from either route file now fails the test. I did not run that deletion to confirm the failure. - End marker: the slice of the one-wave handler now ends at the next
router.add(instead of the unrelated "Keep a thought exactly as typed" comment. - Title: I dropped "(none)" from the test title.
I did not change the list handler's slice, which already ends at the one-wave route's path. test/openapi-oa-waves.test.ts passes (6 tests) and tsc is clean. I did not run scripts/gate.ts this time.
🤖 Generated with Claude Code
All three earlier asks are met: a test now pins the summary wording on both routes, the one-wave slice ends at the next router.add(, and the title no longer says (none). Both handlers read no query parameter, the tests assert that, and the summaries say so. I did not see the wording in the preview output (my grep of openapi.json returned nothing), so I judged it from the diff and handlers.
Non-blocking: the Takes no query parameters wording lives in the summary as prose; a typed empty query marker on Route would be sturdier.
Non-blocking: add a negative test showing the comparison fails when a handler reads a parameter.
Neither waves handler reads a query parameter, so the routes now say they take none and the test checks that.
next_cursoris always null. Neither route gets aqueryentry.test/openapi-oa-waves.test.tsalready compared the route's parameters to the handler's reads. It now also asserts that the handler reads none. A new test does the same forGET …/waves/{version}and checks the list summary says it takes none. If either handler later readssearchParams.get("x")without the route listingx, the comparison fails.test/openapi-oa-waves.test.tspasses (5 tests), andtscandscripts/gate.tsreport nothing. I did not run the rest of the suite; the forge runs the full check on push.To try it, open
/api/v1/openapi.jsonand look at the two waves paths.🤖 Generated with Claude Code
Closes #11359