Close the socket after each response instead of leaking a descriptor

[malpern]

The bug

NetworkSession is created per connection, and nothing retains it — NetworkListener makes it a local, calls start(), and lets it go. The only strong reference is the [self] capture inside the receive handler, which is released as soon as that handler returns.

The response path then cancelled the connection through weak self:

connection.send(content: responseData, completion: .contentProcessed { [weak self] _ in
    self?.connection.cancel()   // self is usually already nil here
})

So NWConnection.cancel() typically never ran, and every served request leaked one file descriptor.

Why it matters

The app runs against a 256 soft file limit. A client polling GET /status once a second — which the bundled browser extension does — exhausts that in well under an hour.

Observed on a live instance: 2,532 sockets stuck in (CLOSED), 2,625 descriptors held, and the listener silently refusing new connections while the menu bar app looked perfectly healthy. Restarting the app "fixes" it until the count climbs again, which makes it easy to misread as a network or firewall problem.

The fix

Capture the connection instead of the session, so cancellation can't depend on session lifetime:

completion: .contentProcessed { [connection] _ in connection.cancel() }

Verification

The new test counts the test process's own open descriptors (via /dev/fd) across a burst of requests, then confirms the listener still answers afterward.

• Against the previous code it fails with "descriptor count grew by 200 over 200 requests" — a clean 1:1 leak.
• With the fix, growth stays near zero and the post-burst request returns 200.
• Full suite: 280 tests in 35 suites pass.

🤖 Generated with Claude Code