-
-
Notifications
You must be signed in to change notification settings - Fork 0
feat:Add x-required-api-key-type extension to three Vectara REST API v2 endpoints #71
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 Vectara REST API v2 was updated to include the Changes
Estimated code review effort1 (~2 minutes) Poem
✨ Finishing Touches🧪 Generate unit tests
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:
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 (
|
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: 0
🧹 Nitpick comments (2)
src/libs/Vectara/openapi.yaml (2)
316-318: Consistent ordering / deduplication of key-types.Double-check that
"QueryService"and"Personal"accurately reflect the backend authorization policy forGET /v2/corpora, and that no additional key types (e.g.IndexService) are required. If policies change frequently, consider deriving this list from the source-of-truth policy file during the SDK build rather than hard-coding it here.
1069-1071: Consider unifying the extension name / semantics with existing security schemes.The spec already defines
security:blocks that reference API-key schemes. Introducing a parallelx-required-api-key-typerisks divergence. If feasible, encode the requirement with standard OpenAPI constructs (multiple named API-key schemes insecurity:) and keep the vendor extension only as supplementary documentation.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/libs/Vectara/openapi.yaml(3 hunks)
🔇 Additional comments (1)
src/libs/Vectara/openapi.yaml (1)
263-264: x-required-api-key-type is correctly aligned at the operation levelThe
x-required-api-key-typeblock sits at the same indentation asresponses,operationId, and the otherx-fern-*extensions under thepostoperation—so it won’t be treated as part of a response object. No changes are needed.
Summary by CodeRabbit