-
-
Notifications
You must be signed in to change notification settings - Fork 1
feat:Clarify accepted formats for version field in Replicate API OpenAPI spec #99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughThe OpenAPI specification for the Replicate API was updated to clarify the accepted formats for the Changes
Poem
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. 🪧 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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/libs/Replicate/openapi.yaml (1)
656-658: Clarify accepted version formats in the example
The updated example for the/predictionsPOST endpoint shows only the full{owner}/{model}:{id}format. Since the schema also accepts a plain 64-character version ID, consider appending a brief note or adding a second cURL snippet demonstrating the legacy-only ID format to cover both supported options.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
src/libs/Replicate/Generated/Replicate.IReplicateApi.PredictionsCreate.g.csis excluded by!**/generated/**src/libs/Replicate/Generated/Replicate.Models.SchemasVersionPredictionRequest.g.csis excluded by!**/generated/**src/libs/Replicate/Generated/Replicate.ReplicateApi.PredictionsCreate.g.csis excluded by!**/generated/**
📒 Files selected for processing (1)
src/libs/Replicate/openapi.yaml(2 hunks)
| version: | ||
| type: string | ||
| description: The ID of the model version that you want to run. | ||
| description: "The ID of the model version that you want to run. This can be specified in two formats:\n\n1. Just the 64-character version ID: `9dcd6d78e7c6560c340d916fe32e9f24aabfa331e5cce95fe31f77fb03121426`\n2. Full model identifier with version ID in the format `{owner}/{model}:{id}`. For example, `replicate/hello-world:9dcd6d78e7c6560c340d916fe32e9f24aabfa331e5cce95fe31f77fb03121426`\n" | ||
| webhook: | ||
| type: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Ensure consistency of version descriptions across schemas
The schemas_version_prediction_request now clearly documents both formats for the version property. However, other parts of the spec (for example, the version field under deployments create/update and in /predictions/{prediction_id}) still reference only the 64-character ID. To maintain uniformity, please align all version property descriptions to mention both supported input formats.
🤖 Prompt for AI Agents (early access)
In src/libs/Replicate/openapi.yaml around lines 1149 to 1153, the description for the `version` property in the `schemas_version_prediction_request` schema includes both supported input formats, but other `version` fields in the spec only mention the 64-character ID format. To fix this, update all `version` property descriptions across the spec, including those under deployments create/update and `/predictions/{prediction_id}`, to consistently document both the 64-character version ID and the full model identifier with version ID format.
Summary by CodeRabbit
versionfield in the API documentation, specifying that it accepts either a 64-character ID or a full model identifier with version ID.versionformats.