OpenAPI omits required revision and upload headers that generated tools require #815

Open
opened 2026-10-02 13:14:49 +00:00 by kayg · 2 comments
Owner

Context: #427 rev-mcp-api review, #484, DESIGN §41. Source base c4a61e8cf090170f35b1bed3350d9de20c83ecd5. Priority: Medium. Source review only; product code is unchanged.

Evidence:

  • crates/plugins/notes/src/reminders_api.rs:165 and :251 declare only path inputs, but :185 and :267 call match_etag with the request headers.
  • crates/plugins/files/src/public.rs:1446 omits the If-Match parameter from the public-edit contract, while :1467 requires it.
  • scripts/action_registry.py:41 adds required If-Match for these three operations. Its tus supplements at :29 also add required upload protocol headers that OpenAPI omits.
  • contracts/openapi.json lacks those header parameters. packages/api-client/src/generated.ts is byte-identical to a regeneration, so it faithfully repeats the omissions. contracts/actions.json declares the extra required headers.

Impact:

An HTTP client or agent using the published OpenAPI schema can send a schema-valid request that the server rejects for a missing required header. The CLI, MCP and WebMCP schemas have a different required-input contract. Fresh generated files do not prevent this semantic drift.

Expected:

Declare existing required protocol and revision headers in the owning route annotations. Generate OpenAPI, actions and the client from that declaration. Remove each corresponding supplement once the primary contract contains it. Preserve revision conflict checks.

Regression test idea:

Assert that these operations expose required If-Match in both OpenAPI and the action schema. Check each tus operation for its required headers. Send requests formed from the documented schemas to the same route and keep stale-revision tests.

Duplicate check:

Searched all issue states for notes_create_block_reminder and action-overrides; read #484. Its general registry scope and documented supplements do not provide a specific issue for these missing primary-contract requirements.

Context: #427 rev-mcp-api review, #484, DESIGN §41. Source base `c4a61e8cf090170f35b1bed3350d9de20c83ecd5`. Priority: Medium. Source review only; product code is unchanged. Evidence: - `crates/plugins/notes/src/reminders_api.rs:165` and `:251` declare only path inputs, but `:185` and `:267` call `match_etag` with the request headers. - `crates/plugins/files/src/public.rs:1446` omits the If-Match parameter from the public-edit contract, while `:1467` requires it. - `scripts/action_registry.py:41` adds required If-Match for these three operations. Its tus supplements at `:29` also add required upload protocol headers that OpenAPI omits. - `contracts/openapi.json` lacks those header parameters. `packages/api-client/src/generated.ts` is byte-identical to a regeneration, so it faithfully repeats the omissions. `contracts/actions.json` declares the extra required headers. Impact: An HTTP client or agent using the published OpenAPI schema can send a schema-valid request that the server rejects for a missing required header. The CLI, MCP and WebMCP schemas have a different required-input contract. Fresh generated files do not prevent this semantic drift. Expected: Declare existing required protocol and revision headers in the owning route annotations. Generate OpenAPI, actions and the client from that declaration. Remove each corresponding supplement once the primary contract contains it. Preserve revision conflict checks. Regression test idea: Assert that these operations expose required If-Match in both OpenAPI and the action schema. Check each tus operation for its required headers. Send requests formed from the documented schemas to the same route and keep stale-revision tests. Duplicate check: Searched all issue states for `notes_create_block_reminder` and `action-overrides`; read #484. Its general registry scope and documented supplements do not provide a specific issue for these missing primary-contract requirements.
Author
Owner

OpenAPI review caught an over-declared precondition in the first pass: the Notes reminder GET handler does not consume If-Match, so it must not publish that header as required. I removed it from the read operation; reminder create/delete retain the required If-Match contract. The regression test checks required headers only on operations that enforce them.

OpenAPI review caught an over-declared precondition in the first pass: the Notes reminder GET handler does not consume `If-Match`, so it must not publish that header as required. I removed it from the read operation; reminder create/delete retain the required `If-Match` contract. The regression test checks required headers only on operations that enforce them.
Author
Owner

The action registry still manufactured Range inputs for download, public_preview, and video_source_by_item, so the exported action schemas hid a missing OpenAPI declaration. I added the route parameters for Range and the validators those handlers read (If-Range and If-None-Match), and removed the generator supplements so declared route contracts are now the source. Mail attachment and saved-Version routes also declare Range; Tus and mutation preconditions remain route-owned. OpenAPI regeneration and final verification are pending.

The action registry still manufactured Range inputs for `download`, `public_preview`, and `video_source_by_item`, so the exported action schemas hid a missing OpenAPI declaration. I added the route parameters for Range and the validators those handlers read (`If-Range` and `If-None-Match`), and removed the generator supplements so declared route contracts are now the source. Mail attachment and saved-Version routes also declare Range; Tus and mutation preconditions remain route-owned. OpenAPI regeneration and final verification are pending.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal#815
No description provided.