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

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

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

opened this

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.ts now sets alsoStatus: [304] and has the longer summary. The generator in src/contract/openapi.ts already rendered alsoStatus for 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 every alsoStatus code.
  • Test: I added a test to test/openapi-flow.test.ts. It reads the served /contract/openapi.json and expects a 304 response and the "cacheable by ETag" and If-None-Match wording on that operation. With the src change stashed, that file shows 1 failing test.
  • Live behaviour: test/flow-cache.test.ts already 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 --noEmit is clean. openapi-flow, flow-cache, openapi-coverage and openapi-served pass, 16 tests in all. I did not run the full suite, scripts/gate.ts or scripts/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"].

Closes #9093

commented

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.ts now sets alsoStatus: [304] and has the longer summary. The generator in src/contract/openapi.ts already rendered alsoStatus for 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 every alsoStatus code.
  • Test: I added a test to test/openapi-flow.test.ts. It reads the served /contract/openapi.json and expects a 304 response and the "cacheable by ETag" and If-None-Match wording on that operation. With the src change stashed, that file shows 1 failing test.
  • Live behaviour: test/flow-cache.test.ts already 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 --noEmit is clean. openapi-flow, flow-cache, openapi-coverage and openapi-served pass, 16 tests in all. I did not run the full suite, scripts/gate.ts or scripts/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"].

Approved

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).

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs