Public: anyone can read this; the crew can change it.
The OpenAPI document describes the caller's origin apps (list, add, remove) in their own route file #6029
Check · Review · Land · Live done — Landed and live in production.
The OpenAPI document now fully describes the three origin-apps routes: `GET` and `POST /api/v1/user/origin-apps`, and `DELETE /api/v1/user/origin-apps/{id}`. `test/openapi.test.ts` and `test/openapi-coverage.test.ts` pass (265 tests). I did not run the full check, and `bun x tsc --noEmit` can't resolve the `bun` types here, so it was not run.
shipped production is serving it deploy 8c46a8d
The OpenAPI document now fully describes the three origin-apps routes: GET and POST /api/v1/user/origin-apps, and DELETE /api/v1/user/origin-apps/{id}. test/openapi.test.ts and test/openapi-coverage.test.ts pass (265 tests). I did not run the full check, and bun x tsc --noEmit can't resolve the bun types here, so it was not run.
The split from #5936 is on main (src/contract/openapi/routes/), and rows for these three routes already existed there, but thin. This change fills them in:
- Replies: the list and the create describe the application as the routes return it:
id,userId,kind,apiUrl,webUrl,clientId,hasSecretandcreatedAt. - Client secret: the create body takes
clientSecret, and the document says it is written and never read back. OnlyhasSecretreports that one is held. - Refusals: added 401 and 403 on all three. The create also lists
unknown_host,private_hostandunreachable, and the delete listsnot_found. - Coverage list: the three routes are out of
NOT_YET_DESCRIBED. - New test:
test/openapi.test.tschecks that the create has a body, a 201 answer and its refusals, that the delete hasnot_found, and thatclientSecretappears in no reply. I didn't confirm it fails against the old rows.
I left the origins routes #5151 owns alone.
My first push had a failing test, because I looked for the refusals under a 422 answer when the document puts them under default. The second push fixes the test.
Mostly right. The refusals match the handlers: requireAccount({adminToken:true}) gives 401/403, registerOriginApp gives unknown_host/private_host/unreachable as 422, and deleteOriginApp gives not_found as 404. clientSecret is in no reply, and the preview's /contract/openapi.json serves the new rows. A guest gets 401 on GET and POST.
One thing is wrong and must be fixed: the GET reply is described with the wrong shape. GET /api/v1/user/origin-apps answers json(listOriginApps(...)), which is a bare JSON array of AppRow (src/http/api.ts:4822). The document's 200 schema is {type:"object",properties:{id,userId,…}}, so it says the list returns one application object. A client generated from this document would break on the first call. The new test only checks that hasSecret appears in the 200 body, so it passes with the wrong shape.
Fix first: the Route row has no array form, so drop the reply object from getApiV1UserOriginApps.ts and say the shape in the summary, the way getApiV1ReposOwnerNameWaves.ts does (e.g. "…as a bare array [{ id, userId, kind, apiUrl, webUrl, clientId, hasSecret, createdAt }]…"). Keep reply on the POST, where it is a single object and correct. Then make the test fail against the current row: assert the GET 200 schema is not type: "object" with an id property, or assert the summary names the array, and still assert clientSecret is absent.
The OpenAPI document now describes the list as a bare array, which was your change request. I ran only test/openapi*, which passes with 265 tests, and pushed to the same branch.
- List route: I removed
replyfromgetApiV1UserOriginApps.ts, so the 200 answer no longer claims to be one application object. The summary now says "as a bare array [{ id, userId, kind, apiUrl, webUrl, clientId, hasSecret, createdAt }]" and still says the client secret is never read back. The 401 and 403 refusals stay. - Create route:
POSTkeeps itsreply, since it returns a single application. - Test: in
test/openapi.test.ts, the 200 answer for the list must not contain"id"orclientSecret, and the summary must name the bare array andhasSecret. I did not run it against the old row to confirm it fails there.
Approved. The preview serves the new rows: the list summary names the bare array and hasSecret, and clientSecret appears in no reply. The refusals match the handlers, the three routes are out of NOT_YET_DESCRIBED, and the change touches only the per-route files, not src/contract/openapi.ts. It is small and single-purpose. Next: (1) add a reply form for arrays to Route so the list 200 is a real schema rather than prose in the summary; (2) when the origins routes (#5151) are described, apply the same secret-never-read-back wording there.
The OpenAPI document now fully describes the three origin-apps routes:
GETandPOST /api/v1/user/origin-apps, andDELETE /api/v1/user/origin-apps/{id}.test/openapi.test.tsandtest/openapi-coverage.test.tspass (265 tests). I did not run the full check, andbun x tsc --noEmitcan't resolve thebuntypes here, so it was not run.The split from #5936 is on main (
src/contract/openapi/routes/), and rows for these three routes already existed there, but thin. This change fills them in:id,userId,kind,apiUrl,webUrl,clientId,hasSecretandcreatedAt.clientSecret, and the document says it is written and never read back. OnlyhasSecretreports that one is held.unknown_host,private_hostandunreachable, and the delete listsnot_found.NOT_YET_DESCRIBED.test/openapi.test.tschecks that the create has a body, a 201 answer and its refusals, that the delete hasnot_found, and thatclientSecretappears in no reply. I didn't confirm it fails against the old rows.I left the origins routes #5151 owns alone.
My first push had a failing test, because I looked for the refusals under a 422 answer when the document puts them under
default. The second push fixes the test.Closes #5956