Repository navigation
docs: clarify async client cleanup - #2388
Merged
Merged
Conversation
RobertCraigie
added
documentation
marcuswood-oai
changed the title
marcuswood-oai
approved these changes
Sep 15, 2026
Contributor
Castiron custom code✅ No new custom-code files detected. 43 mixed files remain; 0 existing customizations changed. Compared 43 existing customizations unchanged
3 more in the full report. 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 35005411841 --repo openai/openai-python \
--name castiron-custom-code-35005411841-1 --dir /tmp/castiron-custom-code-35005411841-1
git apply --stat /tmp/castiron-custom-code-35005411841-1/custom-code.patch
cat /tmp/castiron-custom-code-35005411841-1/custom-code.patchOr reproduce it from an SDK checkout containing the vendored reporter: git fetch --no-tags origin 1493321affb1814fba7b669892e376a119d8d36f 709862d746a1f8c7e24cc2e116fc5a03026bb5db
python3 scripts/castiron/custom_code_report.py report \
--base 1493321affb1814fba7b669892e376a119d8d36f \
--head 709862d746a1f8c7e24cc2e116fc5a03026bb5db --fetch --require-head-hash --public \
--out /tmp/castiron-custom-code-709862d746a1
cat /tmp/castiron-custom-code-709862d746a1/custom-code.patchThis is the current full custom patch for mixed files, not an attribution of only the handwritten lines changed by this PR. |
Contributor
|
Thanks for documenting the cleanup issue you encountered when switching to the async client. |
Merged
pull Bot
pushed a commit
to Pyrex77/openai-python
that referenced
this pull request
Sep 15, 2026
Automated Release PR --- ## [3.14.1](openai/openai-python@v3.14.0...v3.14.1) (2026-09-15) ### Bug Fixes * **client:** validate retry limits and preserve application errors ([openai#3867](openai#3867)) ([f86c721](openai@f86c721)) * correct typo "th" to "the" in StreamAlreadyConsumed error message ([openai#3022](openai#3022)) ([7186203](openai@7186203)) * **examples:** correct Azure endpoint hostname ([openai#3298](openai#3298)) ([543516c](openai@543516c)) * **examples:** refresh chat streaming examples ([openai#2974](openai#2974)) ([54f460e](openai@54f460e)) * **examples:** split push-to-talk shebang arguments ([openai#3210](openai#3210)) ([d241ed6](openai@d241ed6)) * **examples:** use uv in remaining Python launchers ([openai#3821](openai#3821)) ([8c76c4f](openai@8c76c4f)) * log only metadata for Live WebSocket diagnostics ([openai#3865](openai#3865)) ([ccc10f5](openai@ccc10f5)) * **responses:** skip structured parsing for commentary ([openai#3861](openai#3861)) ([6520df1](openai@6520df1)) ### Chores * **examples:** bump module_client.py to gpt-5.6 ([openai#3211](openai#3211)) ([1493321](openai@1493321)) * remove unused fine-tuning data validators ([openai#3863](openai#3863)) ([9640f29](openai@9640f29)) ### Documentation * clarify async client cleanup ([openai#2388](openai#2388)) ([a3d83b5](openai@a3d83b5)) * clarify filenames for in-memory file uploads ([openai#3729](openai#3729)) ([cb27380](openai@cb27380)) * **client:** correct retry jitter comment ([openai#2252](openai#2252)) ([bdbbc16](openai@bdbbc16)) * fix Realtime docstring wording ([openai#3535](openai#3535)) ([8cb9ded](openai@8cb9ded)) * fix reusing wording in Azure client docstrings ([openai#3061](openai#3061)) ([dc625f9](openai@dc625f9)) * fix streaming comment typo ([openai#3005](openai#3005)) ([d421d7a](openai@d421d7a)) * fix vector store polling helper paths ([openai#3101](openai#3101)) ([2ef2de6](openai@2ef2de6)) * **readme:** correct SSE terminology ([openai#2837](openai#2837)) ([caaa9b4](openai@caaa9b4)) * update Responses API reference link ([openai#3279](openai#3279)) ([557bd06](openai@557bd06)) * **utils:** correct query component RFC reference ([openai#3300](openai#3300)) ([929a8a5](openai@929a8a5)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: openai-sdks[bot] <284451331+openai-sdks[bot]@users.noreply.github.com>
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
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.
Changes being requested
When using multiple AsyncOpenAI clients to send records to a local vLLM server, we ran into an issue with garbage collection after switching from the sync client to the async client. We started seeing a bunch of errors like:
which indicated that the event loop was being closed before we could close the client. Concurrently, we saw degraded performance. When we switched to
withblocks for resource management, the problem went away (PR - https://github.com/apache/beam/pull/35053/files). I seems like relying on normal garbage collection calling https://github.com/openai/openai-python/blob/f588695f77aad9279a355f5f483d8debf92b46ed/src/openai/_base_client.py#L1318C21-L1318C37 can cause a meaningful performance issue because the event loop can be destroyed before the client cleanup finishes.Its not clear to me if the slowness was caused by:
Regardless, it would be nice to doc this since switching clients did not work without some minor changes.