- Notifications
You must be signed in to change notification settings - Fork25
Only allow one auth method on the server bindings#589
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
claudebot commentedNov 27, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Claude finished@dani-garcia's task ——View job Review CompleteSummaryThis PR modifies the OpenAPI mustache template to prevent duplicate auth method code generation when multiple servers are defined in the schema. The change uses FindingsFinding 1: Template change is correct and effective for the stated goal. The addition of Finding 2: 💭 Consider edge cases with multiple different auth methods. The current implementation assumes all servers share the same auth method. If a future schema defines servers with different auth methods (e.g., Server 1 uses OAuth, Server 2 uses API key), this change would silently ignore all but the first. While this scenario seems unlikely given the PR description, it might be worth documenting this assumption. Rationale and potential alternativesThe template iterates through // Before: With US and EU servers both using oauth_access_tokenifletSome(ref token) = config.oauth_access_token{ request = request.bearer_auth(token.to_owned());};ifletSome(ref token) = config.oauth_access_token{ request = request.bearer_auth(token.to_owned());};// After: Only one auth blockifletSome(ref token) = config.oauth_access_token{ request = request.bearer_auth(token.to_owned());}; If schemas ever have different auth per server, you'd need to deduplicate by auth type rather than position, but that's significantly more complex and currently unnecessary. Finding 3: 🎨 PR description could include example of generated code impact. The PR description shows the before/after for generated Rust code, which is excellent. Consider also showing the template change itself to help reviewers understand the mustache syntax if they're unfamiliar with it. Good Practices Observed
VerificationThe change correctly:
|
github-actionsbot commentedNov 27, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
🔍 SDK Breaking Change Detection ResultsSDK Version:
Breaking change detection completed.View SDK workflow |
Great job! No new security vulnerabilities introduced in this pull request |
codecovbot commentedNov 27, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@## main #589 +/- ##======================================= Coverage 79.46% 79.46% ======================================= Files 302 302 Lines 32331 32331 ======================================= Hits 25691 25691 Misses 6640 6640 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
2cca3d4 intomainUh oh!
There was an error while loading.Please reload this page.
…th method on the server bindings (bitwarden/sdk-internal#589)

🎟️ Tracking
📔 Objective
The server bindings template iterates over all auth methods of all the servers and generates code for each of them. This means that if the schema has two servers defined (like the US and EU servers) it will generate code like this:
This won't break anything and is safe to do, but it's kind of wasteful. Instead, we can just use the first auth method only.
The change doesn't have any effect on the bindings for the moment as we're only ever defining one server and one auth method, butbitwarden/server#6653 will add the US and EU servers to the server API schema, which will result in the above shown duplication.
🚨 Breaking Changes
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes