← Back to PRs

#8494: fix(test): resolve flaky port race condition in chutes-oauth.test.ts

by gavinbmoore open 2026-02-04 03:04 View on GitHub →
commands stale
## Summary Fix intermittent test failure in `chutes-oauth.test.ts` caused by TCP port race condition. ## Problem The test's `getFreePort()` function had a race condition: 1. Opens server on port 0, OS assigns a port 2. **Closes server immediately** and returns port number 3. ❌ Window where another parallel test can grab the same port 4. `loginChutes()` tries to listen on the port → EADDRINUSE or 'bad port' This caused intermittent failures when running the full test suite with 16 workers. ## Solution 1. **Hold port until needed**: Changed `getFreePort()` to return `{ port, release }` instead of just the port number. The server stays open until `release()` is called. 2. **Sequential execution**: Wrapped test suite in `describe.sequential` to prevent parallel tests from racing for ports during the release window. ## Testing - `pnpm vitest run src/commands/chutes-oauth.test.ts` - passes - TypeScript compiles cleanly - Lint passes Closes #8337 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates `src/commands/chutes-oauth.test.ts` to reduce flakiness from TCP port selection by changing `getFreePort()` to return `{ port, release }` and wrapping the suite in `describe.sequential`. The test now reserves a port, builds a redirect URI from it, then releases the reservation before invoking `loginChutes()` so the code under test can bind. The overall approach is directionally correct, but the release helper currently swallows close errors and the reserve-then-release pattern can still race across Vitest workers/processes. <h3>Confidence Score: 3/5</h3> - This PR is likely safe to merge and should reduce flakiness, but it may not fully eliminate the port race in multi-worker runs. - Changes are isolated to a test file and improve port handling, but `release()` ignores close errors and the port can still be stolen between release and bind across workers/processes; if the original flake was frequent under high parallelism, this may only reduce frequency rather than fully resolve it. - src/commands/chutes-oauth.test.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs