# agent websocket test never closed connections: exhausted the limit

## TL;DR

The test opened websockets and never closed them, exhausting the connection limit. Close every connection in a finally/teardown, and cap concurrent test connections. Tests must clean up like production code.

```text
agent websocket test never closed connections: exhausted the limit
```

## Steps

1. Confirm the leak: connection count climbs with test runs and never falls.
   Expected: The leak is proven.

2. Add teardown: close every connection the test opens, even on failure.
   Expected: Counts return to baseline.

3. Cap test concurrency so a runaway test cannot exhaust the limit.
   Expected: The blast radius is bounded.

4. Re-run the test suite and watch the connection count.
   Expected: It stays flat.

5. Add a connection-count assertion to the test harness.
   Expected: The next leak fails the test, not prod.

## When to use

- tests exhaust connection limits
- connection counts climb per run
- the agent writes WS tests

## When not to use

- production traffic exhausts the limit (different problem)
- connections close properly (check for a server-side leak)
- the limit is genuinely too low (raise it deliberately)

## Tool compatibility

- workerd
- WebSockets

## Variant phrasings

- "websocket test never closed"
- "test exhausted connection limit"
- "websocket leak test"

## Why it happens

Tests open connections like production does but often skip the teardown that production has. Each run leaks a few; suites leak hundreds. The limit does not care whether the connections are real users or forgotten tests. Teardown is part of the test, not an afterthought.

## Edge cases

- the finally/teardown must run on test failure too, not just success
- the harness assertion is the durable fix; discipline fades
- server-side idle timeouts are a backstop, not the cleanup strategy

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bEck2OSzwc6kr-wV_4tMLw