What goes wrong when an automated case leaves the push connection it opened still open?

## Four things a leaked connection does A push connection is not just a client object; it is a pair of allocations, one on each side, plus something running that consumes deliveries. Leaving it open after the case ends has four distinct consequences, and only the first is the one people expect. 1. **Handles accumulate.** Every leaked connection holds a handle the operating system counts on the runner and a registration on the system under test. Long before a suite finishes, a run that leaks one connection per case starts failing on limits - and it fails in cases that have nothing to do with the leak, which sends triage to the wrong place entirely. 2. **The leaked receiver keeps collecting.** It is still appending deliveries into a buffer that outlived its case. A later case that matches loosely - on the newest item, on a type, on anything but its own injected identifier - can be satisfied by traffic an earlier case caused. That is a false green, and a false green looks exactly like a real pass. 3. **The system under test behaves differently.** Fan-out cost grows with the number of live subscriptions. A run that accumulates hundreds of them is measuring a configuration nobody deploys, so its timing observations stop meaning anything. 4. **The run will not exit.** A receiving loop that is still alive holds the process open. The tell is unmistakable once you have seen it: all case results are reported, and then the job simply runs out its clock with nothing on the output. ## Why the close ends up in the wrong place Almost always because it was written as the last line of the case body. That placement is correct only on the happy path, and it fails on precisely the runs where it matters: **a failed assertion leaves the body early**, so the cases that fail are the ones that leak. The leak therefore grows fastest on a bad day, when the run is already red and hardest to read. The same is true of any close guarded by a condition that a failure can skip, and of a close that lives after an early return. ## Register the release beside the acquisition The fix is placement, not diligence. At the moment the case opens the connection, register its release with the per-case cleanup the harness runs on pass, failure and error alike. The two lines sit together, so nobody can add an early return that skips one, and a reviewer can see the pairing without reading the rest of the case. Where a helper opens the connection, the helper registers the cleanup - never the caller. A helper that hands back an open connection and trusts every future caller to release it is a leak waiting for its first hurried change. ## Closing deterministically Fire-and-forget is not closing. | Close style | What it leaves behind | |---|---| | Last line of the case body | Every failing case's connection, which is the worst possible selection | | Fire the close, return immediately | A window where deliveries still land in the old buffer and the far side still holds the registration | | Detach the receiver, close, wait for closed with a bound | Nothing, and the wait is bounded so cleanup cannot hang the run | Order matters inside that last row. **Detach the receiver first**, then close. Detaching first stops deliveries reaching a buffer whose case has ended; closing first leaves a brief window in which they still arrive. Then wait for the connection to report closed, with a bound, so a far side that never answers costs a few seconds rather than the whole job. Make the close idempotent too. A case that closes explicitly and then hits the registered cleanup should not throw on the second attempt; check for already-closed and return. ## Cleanup that cannot itself fail the run A close that throws after the assertions have run tells you nothing about the behaviour under test. Turning it into a case failure produces red runs nobody trusts, and people start ignoring the colour. Swallow the error, log it with enough detail to identify which connection it was, and let a separate systemic check catch a real problem: - Count live connections at the end of the run and assert the count returned to its baseline. - Count how often the bounded close wait expired; a rising number means the far side is struggling, which is a finding about the system rather than about the suite. That split keeps the case's verdict about the product and moves housekeeping problems into a place where they are visible without being confused with defects. ## The rule in one line Whatever a case opens, the case gives back - through a path the harness runs whatever the outcome, in an order that stops deliveries before it releases the connection, with a bound so cleanup can never be the thing that hangs the run.