fix(openai): build Codex async headers off the event loop in _agenerate - #38129
Merged
Conversation
…ate` The Codex `_astream` path was reworked to build its auth headers from an async-fetched token, but `_agenerate` was left on the old "prime the cache, then read it back synchronously" approach. That sync read still went through `_FileChatGPTOAuthTokenProvider.get_token`, which acquires a thread lock and a cross-process file lock on every call — blocking the event loop even when the token is already warm. Both async paths now build headers the same way, so neither touches sync `get_token` on the loop. ## Changes - `_ChatOpenAICodex._agenerate` now fetches the token via `aget_token`, builds the Codex headers off-loop, and hands them to `_get_request_payload` through the private `_codex_headers` kwarg — eliminating the synchronous token read (and its lock acquisition) that previously ran on the event loop inside `super()._agenerate`. - Replaced the duplicated `"_codex_headers"` string literal across `_agenerate`, `_astream`, and `_get_request_payload` with a `_CODEX_HEADERS_KWARG` module constant, documenting that the kwarg is popped before the payload reaches the SDK. - Documented the deliberate `is not None` check in `_get_request_payload`: an explicitly-built empty header dict (accountless token with `originator=None`) is honored as-is rather than falling back to the blocking sync read.
github-actions
Bot
added
fix
![open-swe[bot]](https://avatars.githubusercontent.com/in/1395372?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Codex
_astreampath was reworked to build its auth headers from an async-fetched token, but_ageneratewas left on the old "prime the cache, then read it back synchronously" approach. That sync read still went through_FileChatGPTOAuthTokenProvider.get_token, which acquires a thread lock and a cross-process file lock on every call — blocking the event loop even when the token is already warm. Both async paths now build headers the same way, so neither touches syncget_tokenon the loop.Changes
_ChatOpenAICodex._ageneratenow fetches the token viaaget_token, builds the Codex headers off-loop, and hands them to_get_request_payloadthrough the private_codex_headerskwarg — eliminating the synchronous token read (and its lock acquisition) that previously ran on the event loop insidesuper()._agenerate."_codex_headers"string literal across_agenerate,_astream, and_get_request_payloadwith a_CODEX_HEADERS_KWARGmodule constant, documenting that the kwarg is popped before the payload reaches the SDK.is not Nonecheck in_get_request_payload: an explicitly-built empty header dict (accountless token withoriginator=None) is honored as-is rather than falling back to the blocking sync read.