chore(release): speed up releases and update roadmap#346
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Anthropic-compatible /v1/messages and /v1/messages/count_tokens endpoints and schemas, extends admin and usage metrics, updates generated OpenAPI/Swagger and docs, and changes the CI release workflow to build draft GitHub releases then publish them in a separate job. ChangesRelease Workflow
Anthropic Messages API and Monitoring
Sequence Diagram(s)sequenceDiagram
participant Client
participant GoModel
participant Anthropic as Anthropic/Provider
participant Audit as Audit/Usage Store
Client->>GoModel: POST /v1/messages
GoModel->>GoModel: validate & normalize (ContentBlock)
GoModel->>Anthropic: forward translated request
Anthropic-->>GoModel: stream/resp + token usage
GoModel->>Audit: record usage (cached/uncached token fields)
GoModel-->>Client: return anthropic-formatted response
Client->>GoModel: GET /admin/audit/detail?log_id=X
GoModel->>Audit: fetch audit entry
Audit-->>GoModel: return audit details
GoModel-->>Client: return audit entry
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR speeds up releases and updates the public API docs. It changes:
Confidence Score: 5/5This looks safe to merge.
Reviews (2): Last reviewed commit: "docs: fix Anthropic messages OpenAPI sch..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
README.md (1)
226-246:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAdd
/admin/audit/detailto the Admin Endpoints table.This PR introduces that endpoint in the OpenAPI docs, but it is missing from README’s user-facing endpoint index.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@README.md` around lines 226 - 246, The README endpoints table is missing the new admin endpoint /admin/audit/detail; add a table row for `/admin/audit/detail` with the correct HTTP method (GET) and a short description like "Detailed audit entry information" so the README matches the OpenAPI docs and PR changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@cmd/gomodel/docs/docs.go`:
- Around line 4057-4061: The OpenAPI schema generation incorrectly emits arrays
of integers for several Anthropic fields; update the docs generation logic so
anthropicapi.Message.content is typed as either a string or an array of
content-block objects (not integer arrays), anthropicapi.MessagesRequest.system
is a string, anthropicapi.ResponseContentBlock.input is an object representing
tool arguments, and anthropicapi.Tool.input_schema is a JSON Schema object.
Locate the schema mappings that produce these entries (the generators that emit
types for Message.content, MessagesRequest.system, ResponseContentBlock.input,
and Tool.input_schema) and change their output types to the correct OpenAPI
schemas (string or array<object> for content, string for system, object for
input and input_schema) so the generated docs match Anthropic’s Message and
structured output shapes.
In `@docs/openapi.json`:
- Around line 4521-4672: The OpenAPI contract models several Anthropic payload
fields as integer[] (e.g., messages[].content, system, content[].input,
tools[].input_schema) which is incorrect; update the related schemas (look for
components/schemas used by the /v1/messages and /v1/messages/count_tokens
request/response refs such as anthropicapi.MessagesRequest, MessagesResponse,
CountTokensResponse and any nested message/content/tool schemas) to accept the
correct union types (string and block/text unions and/or arbitrary JSON objects
as appropriate) instead of integer[], then regenerate the docs so the published
spec serializes valid Anthropic payloads.
---
Outside diff comments:
In `@README.md`:
- Around line 226-246: The README endpoints table is missing the new admin
endpoint /admin/audit/detail; add a table row for `/admin/audit/detail` with the
correct HTTP method (GET) and a short description like "Detailed audit entry
information" so the README matches the OpenAPI docs and PR changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: e116834a-3bb7-4150-b649-3048cd773387
📒 Files selected for processing (9)
.github/workflows/release.yml.goreleaser.yamlREADME.mdcmd/gomodel/docs/docs.godocs/about/roadmap.mdxdocs/advanced/guardrails.mdxdocs/features/cache.mdxdocs/features/failover.mdxdocs/openapi.json
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/openapi.json (1)
4539-4542:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winFix
/v1/messagestext/event-streamschema to match SSE event frames, notMessagesResponse.
docs/openapi.jsonmaps thetext/event-streamcontent type to#/components/schemas/anthropicapi.MessagesResponse, but Anthropic’s/v1/messagesstreaming uses named SSE event frames (e.g.,message_start,content_block_start,content_block_delta,message_delta,message_stop) rather than repeating aMessage(s)-shaped response object. This mismatch will mislead SDK/client generators about the actual wire format.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/openapi.json` around lines 4539 - 4542, The OpenAPI entry for the /v1/messages response currently maps the text/event-stream content type to components/schemas/anthropicapi.MessagesResponse, which is incorrect for Anthropic SSE framing; update the spec so text/event-stream references a schema that models named SSE event frames (e.g., an object/oneOf describing event types like message_start, content_block_start, content_block_delta, message_delta, message_stop) instead of anthropicapi.MessagesResponse. Concretely, replace the text/event-stream schema reference to a new/reused schema such as components/schemas/anthropicapi.SSEEventFrame (or an array/stream of such frames) and add the corresponding event-type discriminated schema definitions so generators will know the actual SSE frame shapes for /v1/messages.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/openapi.json`:
- Around line 8309-8311: The OpenAPI schema defines
anthropicapi.ContentBlock.source as only an object but needs to accept either a
string or an object; update the schema for the property named "source" under
anthropicapi.ContentBlock to allow both types (e.g., use oneOf/anyOf with a
string schema and an object schema that keeps additionalProperties: true) so
search_result blocks can be strings while image/document blocks remain
structured objects.
---
Outside diff comments:
In `@docs/openapi.json`:
- Around line 4539-4542: The OpenAPI entry for the /v1/messages response
currently maps the text/event-stream content type to
components/schemas/anthropicapi.MessagesResponse, which is incorrect for
Anthropic SSE framing; update the spec so text/event-stream references a schema
that models named SSE event frames (e.g., an object/oneOf describing event types
like message_start, content_block_start, content_block_delta, message_delta,
message_stop) instead of anthropicapi.MessagesResponse. Concretely, replace the
text/event-stream schema reference to a new/reused schema such as
components/schemas/anthropicapi.SSEEventFrame (or an array/stream of such
frames) and add the corresponding event-type discriminated schema definitions so
generators will know the actual SSE frame shapes for /v1/messages.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 47abcae2-cadb-4651-82c3-c1632bfda8f7
📒 Files selected for processing (6)
MakefileREADME.mdcmd/gomodel/docs/docs.godocs/openapi.jsontools/openapi-postprocess.mjstools/swagger-postprocess.mjs
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tools/openapi-postprocess.mjs`:
- Around line 249-260: The current schemas["anthropicapi.SSEEventFrame"] oneOf
is closed to known event types and will reject unknown future SSE events; add a
generic fallback schema (e.g., components schema named
"anthropicapi.SSEUnknownEvent") and include it in the oneOf list after the
existing refs so validators/codegen will accept unknown event names; implement
the SSEUnknownEvent schema to minimally allow an "event" string and an open JSON
"data" object (additionalProperties: true) so unknown event frames are accepted
without breaking existing typed events; update any references or docs to mention
the fallback but keep the original specific event schemas unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 8e30423d-5abd-469c-9b08-811e15e071ca
📒 Files selected for processing (2)
docs/openapi.jsontools/openapi-postprocess.mjs
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tools/openapi-postprocess.mjs (1)
249-270:⚠️ Potential issue | 🟠 Major | ⚡ Quick winFix
SSEEventFrameunion so the unknown event fallback can’t swallow all known eventsIn
tools/openapi-postprocess.mjs(lines 249-270),anthropicapi.SSEUnknownEventmatches any payload with atype, so withSSEEventFrameusinganyOf, that branch overlaps every concrete event and degrades generated typings/type discrimination. Keep a discriminatedoneOffor the knowntypevalues, and handle forward-compatible payloads via a separate catch-all (e.g., an outeranyOfwrapper) rather than relying onnot-based exclusion in the fallback—complexnotconstraints are frequently unsupported/ignored by generators.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tools/openapi-postprocess.mjs` around lines 249 - 270, SSEEventFrame currently uses anyOf with the catch-all SSEUnknownEvent which overlaps all concrete event schemas; change SSEEventFrame so the known event branch is a discriminated oneOf (use oneOf with a discriminator on "type" referencing the concrete refs: SSEMessageStartEvent, SSEContentBlockStartEvent, SSEContentBlockDeltaEvent, SSEContentBlockStopEvent, SSEMessageDeltaEvent, SSEMessageStopEvent, SSEPingEvent, SSEErrorEvent) and then wrap that oneOf and the catch-all SSEUnknownEvent in an outer anyOf (i.e., SSEEventFrame.anyOf = [ { oneOf: [ <known refs> ], discriminator: { propertyName: "type" } }, { $ref: "`#/components/schemas/anthropicapi.SSEUnknownEvent`" } ]) so generators can discriminate known types while still allowing a forward-compatible fallback.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@tools/openapi-postprocess.mjs`:
- Around line 249-270: SSEEventFrame currently uses anyOf with the catch-all
SSEUnknownEvent which overlaps all concrete event schemas; change SSEEventFrame
so the known event branch is a discriminated oneOf (use oneOf with a
discriminator on "type" referencing the concrete refs: SSEMessageStartEvent,
SSEContentBlockStartEvent, SSEContentBlockDeltaEvent, SSEContentBlockStopEvent,
SSEMessageDeltaEvent, SSEMessageStopEvent, SSEPingEvent, SSEErrorEvent) and then
wrap that oneOf and the catch-all SSEUnknownEvent in an outer anyOf (i.e.,
SSEEventFrame.anyOf = [ { oneOf: [ <known refs> ], discriminator: {
propertyName: "type" } }, { $ref:
"`#/components/schemas/anthropicapi.SSEUnknownEvent`" } ]) so generators can
discriminate known types while still allowing a forward-compatible fallback.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 2ca95d0f-c3d5-453f-9a54-211201bc5ea3
📒 Files selected for processing (2)
docs/openapi.jsontools/openapi-postprocess.mjs
2 participants
Summary
Verification
Summary by CodeRabbit
New Features
Documentation
Chores