feat(api): Add expiration controls for service account keys - #3825
feat(api): Add expiration controls for service account keys#3825apcha-oai wants to merge 1 commit into
Conversation
Castiron-Internal-PR: openai/openai-python-internal#93 Castiron-Source-SHA: 9c43ef94671d731e89ee97a28a600fa31161a569 Castiron-Public-Base-SHA: 8011140
Castiron custom code✅ No new custom-code files detected. 36 mixed files remain; 0 existing customizations changed; 20 generated baselines changed. Compared
16 existing customizations unchanged
A changed generated baseline means this report cannot reliably identify which handwritten lines changed. Inspect the custom-code diffDownload the exact patch produced by this run (requires repository access): gh run download 34301302891 --repo openai/openai-python \
--name castiron-custom-code-34301302891-1 --dir /tmp/castiron-custom-code-34301302891-1
git apply --stat /tmp/castiron-custom-code-34301302891-1/custom-code.patch
cat /tmp/castiron-custom-code-34301302891-1/custom-code.patchOr reproduce it from an SDK checkout containing the vendored reporter: git fetch --no-tags origin 8011140bbeb771d56425602950875bf87beae39e c61d4971dae3d381219ccd7888de067f0e837e1b
python3 scripts/castiron/custom_code_report.py report \
--base 8011140bbeb771d56425602950875bf87beae39e \
--head c61d4971dae3d381219ccd7888de067f0e837e1b --fetch --require-head-hash --public \
--out /tmp/castiron-custom-code-c61d4971dae3
cat /tmp/castiron-custom-code-c61d4971dae3/custom-code.patchThis is the current full custom patch for mixed files, not an attribution of only the handwritten lines changed by this PR. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c61d4971da
ℹ️ 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".
| project_id="project_id", | ||
| name="name", | ||
| create_service_account_only=True, | ||
| expires_in_seconds=1, |
There was a problem hiding this comment.
Test expiration with API-key creation enabled
This success-path test combines expires_in_seconds with create_service_account_only=True, although the new parameter documentation explicitly says a non-null expiration cannot be used in that mode because no initial API key is created. A backend-aware contract test would reject this request, and the current test therefore does not demonstrate that expiration works on a successful service-account creation; use False (or omit the flag) here and in the asynchronous copy.
Useful? React with 👍 / 👎.
markstuart-oai
left a comment
There was a problem hiding this comment.
Reviewed the expiration request/response contracts, sync/async serialization, generated schema changes, and documentation refresh. The implementation extends the existing request/model paths without adding special-case runtime logic. Offline expiration probes and all 56 transform tests passed. One low-priority correction below keeps the generated success fixture consistent with the documented API contract.
| project_id="project_id", | ||
| name="name", | ||
| create_service_account_only=True, | ||
| expires_in_seconds=1, |
There was a problem hiding this comment.
[P3] Use a valid key-creation combination in the expiration fixture
expires_in_seconds=1 is combined with create_service_account_only=True, but that mode creates no key and the documented contract rejects a non-null expiration. Please set create_service_account_only=False (or omit it) in this test and the asynchronous copy at line 298. These are generated SDK smoke tests rather than backend contract tests, so this does not indicate a shipped serialization defect, but their success fixtures should still represent valid requests.
jbeckwith-oai
left a comment
There was a problem hiding this comment.
Two in-scope blockers remain on this exact head. The new service-account test sends expires_in_seconds together with create_service_account_only=True even though the documented contract forbids that combination, so it does not exercise a successful expiring-key request (see the existing inline thread). Also, the shared moderation-model documentation now labels a link as “available models” but points it back to the moderation guide in api_reference/openapi.transformed.yml; that link should target the models documentation. Please correct the source and regenerate.
Summary
Allow project service accounts to create initial API keys with a configurable lifetime and expose their expiration timestamps. Clarify related API behavior and refresh inline documentation links.
Changes
expires_in_secondsparameter to synchronous and asynchronous service account creation and its request type.create_service_account_only.expires_atexpiration metadata to project API key and service account creation response types.gpt-4o-transcribe-diarize.