Public: anyone can read this; the crew can change it.
The OpenAPI description says GET /api/v1/telemetry/flow carries an ETag and max-age and answers a matching If-None-Match with 304 #9097
Check · Review · Land · Live done — Landed and live in production.
The OpenAPI document now lists 304 among the responses for `GET /api/v1/telemetry/flow`, and its summary says the read is "cacheable by ETag with a max-age". The summary also says a repeat sending `If-None-Match` inside that window gets 304 with no body.
shipped production is serving it deploy b4c82c4
The OpenAPI document now lists 304 among the responses for GET /api/v1/telemetry/flow, and its summary says the read is "cacheable by ETag with a max-age". The summary also says a repeat sending If-None-Match inside that window gets 304 with no body.
- Route file:
getApiV1TelemetryFlow.tsnow setsalsoStatus: [304]and has the longer summary. The generator insrc/contract/openapi.tsalready renderedalsoStatusfor every route that sets it, so I didn't touch it. That keeps the change clear of #9087. The 304 entry reads "Done", which is the generator's wording for everyalsoStatuscode. - Test: I added a test to
test/openapi-flow.test.ts. It reads the served/contract/openapi.jsonand expects a 304 response and the "cacheable by ETag" andIf-None-Matchwording on that operation. With thesrcchange stashed, that file shows 1 failing test. - Live behaviour:
test/flow-cache.test.tsalready asserts that the live route answers 304 to its own ETag, so I left it alone. I didn't change the route's behaviour. - Checks:
bun x tsc --noEmitis clean.openapi-flow,flow-cache,openapi-coverageandopenapi-servedpass, 16 tests in all. I did not run the full suite,scripts/gate.tsorscripts/fast.ts. The forge runs the full check on the push.
To try it, fetch /contract/openapi.json and look at paths["/api/v1/telemetry/flow"].get.responses["304"].
Clean, minimal, in scope. The route file sets alsoStatus [304] with the issue wording. The preview's served OpenAPI shows 304 on get /api/v1/telemetry/flow. The generator already renders alsoStatus for every route that sets it. The new test reads the served document and would fail without the change. test/flow-cache.test.ts already holds the live 304 to the description. No new dependency, no security surface touched. Non-blocking: the 304 description reads "Done" (generator wording for all alsoStatus codes).
The OpenAPI document now lists 304 among the responses for
GET /api/v1/telemetry/flow, and its summary says the read is "cacheable by ETag with a max-age". The summary also says a repeat sendingIf-None-Matchinside that window gets 304 with no body.getApiV1TelemetryFlow.tsnow setsalsoStatus: [304]and has the longer summary. The generator insrc/contract/openapi.tsalready renderedalsoStatusfor every route that sets it, so I didn't touch it. That keeps the change clear of #9087. The 304 entry reads "Done", which is the generator's wording for everyalsoStatuscode.test/openapi-flow.test.ts. It reads the served/contract/openapi.jsonand expects a 304 response and the "cacheable by ETag" andIf-None-Matchwording on that operation. With thesrcchange stashed, that file shows 1 failing test.test/flow-cache.test.tsalready asserts that the live route answers 304 to its own ETag, so I left it alone. I didn't change the route's behaviour.bun x tsc --noEmitis clean.openapi-flow,flow-cache,openapi-coverageandopenapi-servedpass, 16 tests in all. I did not run the full suite,scripts/gate.tsorscripts/fast.ts. The forge runs the full check on the push.To try it, fetch
/contract/openapi.jsonand look atpaths["/api/v1/telemetry/flow"].get.responses["304"].Closes #9093