test: stabilize proxy tests#1762
Conversation
4e5b9f3 to
95b285f
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 95b285f. Configure here.
| stdout_bytes, _ = proxy_process.communicate() | ||
| stdout = stdout_bytes.decode("utf-8", errors="replace") | ||
| stdout_bytes, _ = proxy_process.communicate(timeout=timeout) | ||
| stdout = "".join(stdout) + stdout_bytes.decode("utf-8", errors="replace") |
There was a problem hiding this comment.
Reader thread and communicate() race on same stdout pipe
Medium Severity
The reader thread reads from proxy_process.stdout via readline(), and then proxy_process.communicate() is called on the same pipe. communicate() internally calls self.stdout.read() followed by self.stdout.close(). If communicate() acquires the BufferedReader lock before the reader thread finishes its loop, it will close the file object, causing the thread's next readline() to raise ValueError. This also means the two readers compete for pipe data — the thread never gets joined, so there's no guarantee it's finished before "".join(stdout) on line 165 is evaluated. The fix would be to avoid calling communicate() and instead use proxy_process.wait() + reader.join() to collect output solely through the reader thread.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 95b285f. Configure here.


Proxy-related tests have been failing quite often lately
Replace the hardcoded 0.5s sleep with a wait loop that gives
mitmdumpup to 10s to get a response from the mock server. This should help in busy CI environments where runners may be under load and processes can be delayed.