feat:Add new endpoints and enhance existing ones in Instill AI API OpenAPI spec #70
Conversation
WalkthroughThe changes to the Instill AI API's OpenAPI specification introduce several new endpoints for managing conversations, messages, and agents, along with updates to existing endpoints. New functionalities include operations for creating, updating, retrieving, and deleting these entities. Enhancements to schema definitions include new fields for better data management and standardized error handling across various endpoints. Overall, these modifications expand the API's capabilities and improve documentation clarity. Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
coderabbitai
bot
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
src/libs/Instill/openapi.yaml (2)
7113-7117: New blob data expiration time fields addedThe addition of
blobDataExpirationTimefields to both ComponentRun and PipelineRun schemas is a good practice for data lifecycle management. This helps clients understand when associated data will no longer be available.Consider adding documentation examples showing the expected timestamp format and behavior when data expires. For example:
blobDataExpirationTime: type: string - description: "Expiration time for the blob data associated with the component run (e.g.\ninput / output data). When the run is accessed after the expiration, that\ninformation will be empty, but this field will allow the user identify\nthat the data isn't there because it has expired." + description: | + Expiration time for the blob data associated with the component run (e.g. + input / output data). When the run is accessed after the expiration, that + information will be empty, but this field will allow the user identify + that the data isn't there because it has expired. + + Example value: "2024-12-31T23:59:59Z" + + When accessing runs after expiration: + - Input/output data fields will be empty + - Other metadata remains accessible + - This timestamp helps identify why the data is not available format: date-time readOnly: trueAlso applies to: 9918-9922
Line range hint
1-1000: Consider standardizing pagination parametersWhile pagination is implemented across list endpoints, there are some variations in parameter naming and defaults. Consider standardizing these for better API consistency.
Standardize pagination parameters across all list endpoints to use:
pageSize(with consistent default of 10 and max of 100)pageTokenfor cursor-based paginationtotalSizein responsesExample standardization:
parameters: - name: page in: query - description: The page number to retrieve. + description: "The maximum number of items to return. Default is 10, maximum is 100." schema: type: integer format: int32 + minimum: 1 + maximum: 100 + default: 10
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
src/libs/Instill/Generated/Instill.Models.ComponentRun.g.csis excluded by!**/generated/**src/libs/Instill/Generated/Instill.Models.PipelineRun.g.csis excluded by!**/generated/**
📒 Files selected for processing (1)
src/libs/Instill/openapi.yaml(2 hunks)
🔇 Additional comments (1)
src/libs/Instill/openapi.yaml (1)
Line range hint 1-1000: Verify error handling consistency across new endpoints
The error handling appears consistent across the new endpoints, with proper 401 unauthorized and default error responses. Let's verify this pattern is followed throughout the API.
✅ Verification successful
✓ Error handling is consistent across all endpoints
Based on the verification results, all endpoints in the OpenAPI specification consistently implement:
- 401 responses for unauthorized access with standard description and schema
- Default error responses for unexpected errors with standard description and schema referencing 'rpc.Status'
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for consistency in error response definitions
rg -A 2 '"401":|"default":'
Length of output: 29
Script:
#!/bin/bash
# Let's try a more specific pattern to match the error response sections in the OpenAPI spec
rg -A 5 "'401':\s*{\s*description:|'default':\s*{\s*description:" src/libs/Instill/openapi.yaml
Length of output: 257
Script:
#!/bin/bash
# Let's try a simpler pattern to match error responses in the OpenAPI spec
rg -A 3 "'401':" src/libs/Instill/openapi.yaml
Length of output: 19363
Script:
#!/bin/bash
# Let's also check for default error responses
rg -A 3 "default':" src/libs/Instill/openapi.yaml
Length of output: 54
Script:
#!/bin/bash
# Try a different pattern to match default responses
rg -A 4 ' default:' src/libs/Instill/openapi.yaml
Length of output: 19639
Summary by CodeRabbit
New Features
Bug Fixes
Documentation