fix: set explicit HTTP timeouts to prevent OOM when network is blocked#1005
fix: set explicit HTTP timeouts to prevent OOM when network is blocked#1005msmolkin wants to merge 2 commits into
Conversation
…s blocked URLSession.shared defaults to timeoutIntervalForResource = 604800s (7 days). When a firewall (LuLu, Little Snitch) blocks CodexBarCLI's network access, requests hang indefinitely while the process accumulates memory — observed 28 GB per CLI instance, triggering Jetsam and crashing the system. Set timeoutIntervalForRequest = 30s and timeoutIntervalForResource = 90s with waitsForConnectivity = false so blocked connections fail fast instead of hanging for a week. Fixes steipete#1004
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e295faf1f8
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let configuration = URLSessionConfiguration.default | ||
| configuration.timeoutIntervalForRequest = 30 | ||
| configuration.timeoutIntervalForResource = 90 | ||
| configuration.waitsForConnectivity = false |
There was a problem hiding this comment.
On Linux builds of the unconditional CodexBarCore/CodexBarCLI targets, URLSessionConfiguration comes from FoundationNetworking, where waitsForConnectivity is get-only; compiling this file fails with cannot assign to property: 'waitsForConnectivity' is a get-only property. The macOS-only behavior is fine, but this assignment needs a platform guard or another cross-platform timeout-only path so the Linux targets/tests continue to build.
Useful? React with 👍 / 👎.
|
Thanks for the report and patch. I landed a maintainer-polished version on main as 3ce4101. Changes before landing:
Proof:
Co-authored-by credit preserved in the landed commit. Thank you. |
2 participants
Summary
timeoutIntervalForRequest = 30sandtimeoutIntervalForResource = 90sonProviderHTTPClient's URLSessionwaitsForConnectivity = falseso blocked connections fail immediately instead of waitingProblem
URLSession.shareddefaults totimeoutIntervalForResource = 604800(7 days). When a firewall blocksCodexBarCLI(e.g. LuLu on macOS blocks unsigned/new CLI binaries by default), every provider fetch hangs indefinitely. With theusagecommand spawning concurrent tasks for all enabled providers, the process accumulates 28 GB+ of memory per instance, triggering Jetsam and crashing the system.Observed on v0.26.1 with LuLu firewall on macOS 15. Two stuck
CodexBarCLIprocesses totaling 56 GB crashed the machine.Fix
One-line change to
ProviderHTTPClient.init: use a customURLSessionConfigurationwith sane timeouts instead ofURLSession.shared.Fixes #1004
Test plan
codexbar usagewith network blocked → should fail within 30s with timeout error instead of hangingcodexbar usagewith network allowed → should work as before