release: 4.34.0#731
Conversation
8a44523 to
3cea452
Compare
329d7d2 to
2244ca2
Compare
2244ca2 to
2df4554
Compare
|
@codex review pls |
There was a problem hiding this comment.
💡 Codex Review
These requests still call prepare(clientOptions, params) and therefore use SecurityOptions.all() by default. When both keys are configured, securityHeaders overwrites Authorization with the admin key, so realtime session calls may send the wrong credential instead of the standard API key.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .prepare( | ||
| clientOptions, | ||
| params, | ||
| SecurityOptions.builder().bearerAuth(true).build(), |
There was a problem hiding this comment.
Use admin auth for checkpoint permission requests
These endpoints are documented as requiring an admin API key, but request prep uses bearerAuth(true) only. If a client is configured with only adminApiKey, ClientOptions.securityHeaders throws before sending the request (requires apiKey or workloadIdentity). This prevents admin-key-only usage on admin-only routes.
Useful? React with 👍 / 👎.
| credential !== AdminApiKeyOnlyCredential -> { | ||
| isSatisfied = true |
There was a problem hiding this comment.
Emit auth headers when bearer auth is marked satisfied
This branch treats any non-AdminApiKeyOnlyCredential credential as satisfying bearer auth but does not add an auth header. With AzureApiKeyCredential (or other custom credentials), bearer-protected requests can go out without Authorization or api-key, yielding unauthenticated failures.
Useful? React with 👍 / 👎.
| !apiKey.isNullOrEmpty() -> { | ||
| headers.replace("Authorization", "Bearer $apiKey") | ||
| isSatisfied = true |
There was a problem hiding this comment.
Preserve last-set credential precedence in auth headers
securityHeaders always prefers the stored apiKey over credential. After fromEnv() or .apiKey(...), a later .credential(...) call does not take effect unless callers also clear apiKey, breaking normal builder “last setter wins” behavior and making credential overrides unexpectedly fail.
Useful? React with 👍 / 👎.
…nknown-validation fix: ignore post-completion response stream events
2df4554 to
2ff744d
Compare
…nix timestamps in responses
Generate SDK for admin.organization.audit_logs.
2ff744d to
80579ea
Compare
80579ea to
3b7c303
Compare
Include all admin APIs in the code generation.
3b7c303 to
3516e8c
Compare
fix(auth): apply route-specific security options
3516e8c to
f3ec3c6
Compare
f3ec3c6 to
8590d34
Compare
8590d34 to
4abbf9d
Compare
4abbf9d to
6491e66
Compare
6491e66 to
bdb9d59
Compare
|
🤖 Release is at https://github.com/openai/openai-java/releases/tag/v4.34.0 🌻 |
Automated Release PR
4.34.0 (2026-05-01)
Full Changelog: v4.33.0...v4.34.0
Features
Bug Fixes
Chores
Documentation
This pull request is managed by Stainless's GitHub App.
The semver version number is based on included commit messages. Alternatively, you can manually set the version number in the title of this pull request.
For a better experience, it is recommended to use either rebase-merge or squash-merge when merging this pull request.
🔗 Stainless website
📚 Read the docs
🙋 Reach out for help or questions