LCORE-304: Update OpenAPI schema #258
Conversation
WalkthroughA new API path Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API
Client->>API: GET /v1/conversations/{conversation_id}
API-->>Client: 200 ConversationResponse / 404 / 503 / 422
Client->>API: DELETE /v1/conversations/{conversation_id}
API-->>Client: 200 ConversationDeleteResponse / 404 / 503 / 422
Possibly related PRs
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
docs/openapi.json (1)
1280-1289: Docstring not updated for newmedia_typefield
QueryRequestnow containsmedia_type, but the schema description (lines 1294-1299) still enumerates only up toattachments. Add a short note so docs generated from the spec stay self-consistent.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/openapi.json(3 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build-pr
🔇 Additional comments (1)
docs/openapi.json (1)
797-810:ConversationResponseis missingsession_datareferenced by the GET exampleEither add an optional
session_dataproperty here or drop it from the example to keep consumer models accurate.Example augmentation:
"chat_history": { ... } + ,"session_data": { + "type": "object", + "additionalProperties": true, + "title": "Session Data" + }
| "200": { | ||
| "description": "Successful Response", | ||
| "content": { | ||
| "application/json": { | ||
| "schema": { | ||
| "$ref": "#/components/schemas/ConversationResponse" | ||
| } | ||
| } | ||
| }, | ||
| "conversation_id": "123e4567-e89b-12d3-a456-426614174000", | ||
| "session_data": { | ||
| "session_id": "123e4567-e89b-12d3-a456-426614174000", | ||
| "turns": [], | ||
| "started_at": "2024-01-01T00:00:00Z" | ||
| } | ||
| }, |
There was a problem hiding this comment.
GET /v1/conversations/{conversation_id} – invalid top-level fields and schema drift
Inside the 200 response you place conversation_id and session_data directly under the Response object. OpenAPI 3.x only allows the keys description, headers, content, and links (plus vendor extensions x-*) at this level.
Additionally, the payload example introduces session_data, which is absent from the referenced ConversationResponse schema – this will fail validation and break code-gen.
- "conversation_id": "123e4567-e89b-12d3-a456-426614174000",
- "session_data": {
- "session_id": "123e4567-e89b-12d3-a456-426614174000",
- "turns": [],
- "started_at": "2024-01-01T00:00:00Z"
- }
+ "content": {
+ "application/json": {
+ "schema": { "$ref": "#/components/schemas/ConversationResponse" },
+ "example": {
+ "conversation_id": "123e4567-e89b-12d3-a456-426614174000",
+ "chat_history": []
+ }
+ }
+ }Either extend ConversationResponse with session_data or keep the example in sync with the current schema.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In docs/openapi.json around lines 390 to 405, the 200 response object
incorrectly includes top-level fields conversation_id and session_data, which
are not allowed by OpenAPI 3.x. To fix this, remove these fields from the
response object and instead add session_data to the ConversationResponse schema
if it is part of the response payload. Ensure the example matches the updated
schema to maintain validation and code generation compatibility.
| "200": { | ||
| "description": "Successful Response", | ||
| "content": { | ||
| "application/json": { | ||
| "schema": { | ||
| "$ref": "#/components/schemas/ConversationDeleteResponse" | ||
| } | ||
| } | ||
| }, | ||
| "conversation_id": "123e4567-e89b-12d3-a456-426614174000", | ||
| "success": true, | ||
| "message": "Conversation deleted successfully" | ||
| }, |
There was a problem hiding this comment.
DELETE /v1/conversations/{conversation_id} – field name & spec compliance issues
- The inline example uses
message, yet the schema defines the property asresponse; clients generated from this spec will reject the returned JSON. conversation_id,success, andmessage/responseare again placed at the wrong level in the Response object, violating the OpenAPI structure.
- "conversation_id": "123e4567-e89b-12d3-a456-426614174000",
- "success": true,
- "message": "Conversation deleted successfully"
+ "content": {
+ "application/json": {
+ "schema": { "$ref": "#/components/schemas/ConversationDeleteResponse" },
+ "example": {
+ "conversation_id": "123e4567-e89b-12d3-a456-426614174000",
+ "success": true,
+ "response": "Conversation deleted successfully"
+ }
+ }
+ }Also rename either the schema field or the example so they match (response vs message).
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In docs/openapi.json around lines 451 to 463, the response example for DELETE
/v1/conversations/{conversation_id} incorrectly places conversation_id, success,
and message fields outside the content schema object, violating OpenAPI
structure. Move these fields inside the schema definition or the example object
within "application/json". Also, ensure the field name in the example matches
the schema property by renaming either "message" to "response" or vice versa for
consistency.
| "ConversationDeleteResponse": { | ||
| "properties": { | ||
| "conversation_id": { | ||
| "type": "string", | ||
| "title": "Conversation Id" | ||
| }, | ||
| "success": { | ||
| "type": "boolean", | ||
| "title": "Success" | ||
| }, | ||
| "response": { | ||
| "type": "string", | ||
| "title": "Response" | ||
| } | ||
| }, | ||
| "type": "object", | ||
| "required": [ | ||
| "conversation_id", | ||
| "success", | ||
| "response" | ||
| ], | ||
| "title": "ConversationDeleteResponse", | ||
| "description": "Model representing a response for deleting a conversation.\n\nAttributes:\n conversation_id: The conversation ID (UUID) that was deleted.\n success: Whether the deletion was successful.\n response: A message about the deletion result.\n\nExample:\n ```python\n delete_response = ConversationDeleteResponse(\n conversation_id=\"123e4567-e89b-12d3-a456-426614174000\",\n success=True,\n response=\"Conversation deleted successfully\"\n )\n ```", | ||
| "examples": [ | ||
| { | ||
| "conversation_id": "123e4567-e89b-12d3-a456-426614174000", | ||
| "response": "Conversation deleted successfully", | ||
| "success": true | ||
| } | ||
| ] | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
ConversationDeleteResponse schema–example mismatch
The schema exposes property response, but the path example (see DELETE 200 above) uses message. Pick one identifier and keep it consistent across schema and examples to avoid runtime deserialization errors.
🤖 Prompt for AI Agents
In docs/openapi.json between lines 766 and 796, the ConversationDeleteResponse
schema defines a property named "response" but the example in the DELETE 200
path uses "message" instead. To fix this, choose either "response" or "message"
as the property name and update both the schema and all examples to use the same
identifier consistently to prevent deserialization errors.
1 participant
Description
LCORE-304: Update OpenAPI schema
Type of change
Related Tickets & Documents
Summary by CodeRabbit
New Features
Documentation