fix(tests): match the OS bind error in the owned-proxy port-race retry

[devin-ai-integration]

TLDR

Problem this solves:

• The owned-proxy launch retry in tests/integration/_support/process.py never fires on a real port collision
• It looks for address already in use, the server logs [Errno 48] Address already in use
• A collision fails the cell with Owned proxy exited before readiness instead of relaunching

How it solves it:

• Match os.strerror(errno.EADDRINUSE), the text the OS puts in the error the server logs
• Regression tests feed _lost_port_race the exact logged line, an unrelated exit, and a live process

User Flow

Before: an engineer running a self-booting integration cell loses the run to a port race the harness was built to survive

1. They run python tests/integration/run.py providers tests/integration/providers/test_decisions_chaos.py
2. The cell reserves a free port and launches its two-worker proxy on it
3. Another process on the box takes that port first, the proxy log ends with ERROR: [Errno 48] Address already in use
4. The cell fails with AssertionError: Owned proxy exited before readiness although two launch attempts are left

After: the same collision is recognized and the launch retries on a fresh port

1. They run the same python tests/integration/run.py providers tests/integration/providers/test_decisions_chaos.py
2. The cell reserves a free port and launches its two-worker proxy on it
3. Another process takes the port first, the proxy log ends with the same [Errno 48] Address already in use line
4. The harness relaunches on a fresh port and the cell runs to its own verdict

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/unit/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Shared setup: a Python socket holds a random free port (50989) on 127.0.0.1, then the harness's own proxy entrypoint is launched on that port exactly the way owned_proxy_process launches it, with the log captured to a file

python3 -c "import socket,time; s=socket.socket(); s.bind(('127.0.0.1', 50989)); s.listen(); time.sleep(600)" &
PYTHONPATH=$PWD:$PWD/tests python -P -m integration._support.proxy --config config.yaml --host 127.0.0.1 --port 50989 --num_workers 2 --telemetry False > owned-proxy.log 2>&1; echo "exit=$?"
grep -n "Errno" owned-proxy.log

exit=3
14:ERROR:    [Errno 48] Address already in use

Before (1a70233)

1. The needle the merge base's _lost_port_race searches for, against that log: grep -c "address already in use" owned-proxy.log
2. Output: 0, so the harness reads the exit as a plain crash and asserts Owned proxy exited before readiness

After (b12759e)

1. The needle the fix searches for, derived from the OS: grep -c "$(python3 -c 'import errno,os; print(os.strerror(errno.EADDRINUSE))')" owned-proxy.log
2. Output: 1 (ERROR: [Errno 48] Address already in use), so the harness relaunches on a fresh port
3. uv run pytest tests/unit/integration_support/test_process.py -q: 3 passed, in-process (the predicate takes the exit code and the log path); with the needle reverted to the lowercase text, test_lost_port_race_matches_the_bind_error_the_server_logs fails

• b12759e passes /audit (skipped: no product code on a request path, tests and test harness only)

Type

🐛 Bug Fix
✅ Test

Caveats (if any)

Low

• The proof shows the needle against the real server's log on a held port, not the harness relaunching inside a real run.py cell, because a collision cannot be forced on a port the harness picks for itself; the retry glue around the predicate is covered by the in-process unit tests, and forcing the race would mean test-only hooks in the harness's port choice for the sake of a proof
• The new unit tests run on main's six-hourly CircleCI unit job, which collects every tests/unit file, not on the PR-time GitHub shards, the same way the sibling test_routing.py does; adding a shard for a two-file harness directory is more CI config than the fix is worth
• The regression tests put tests/ on sys.path through monkeypatch.syspath_prepend to import the harness module, which imports its siblings as integration._support.* the way CI's PYTHONPATH resolves them; a tests.-rooted import would need the harness to change how it imports its siblings, more churn than a two-line fixture

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

• b12759e passes /live-pr-risk

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[greptile-apps]

Confidence Score: 5/5

[Low risk] Test support code for port-binding retry logic.

The PR appears safe to merge; no outstanding actionable finding was identified.

Findings

1.  Regression tests miss unit CI ▶

Summary

The PR updates the owned-proxy harness to recognize the OS bind-collision message and adds in-process regression tests. The subsequent revision removes subprocess fixtures and passes the polled exit status directly to the collision predicate.

_{Reviews (2) · Last reviewed commit: "test(integration): keep the port-race pr..."}

[greptile-apps]

Regression tests miss unit CI The unit workflow runs selected paths, but no shard selects tests/unit/integration_support. These new tests therefore will not run there, leaving the bind-error fix without CI regression coverage

[mateo-berri]

The tests run in CI: the CircleCI unit job collects every tests/unit file on main every six hours, the same path the sibling test_routing.py takes

[greptile-apps]

You're right — my comment incorrectly assumed that the unit workflow only runs explicitly listed shard paths. The six-hour CircleCI unit job collects tests/unit on main, so tests/unit/integration_support/test_process.py is covered just like the sibling test_routing.py.

This finding is invalid; no CI configuration change is needed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mateo-berri]

@greptileai

[mateo-berri]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit b12759e. Configure here.}

[mateo-berri]

LGTM