File, socket or timer opened and never closed
A file, socket, cursor or interval opened and never released.
Why it matters
An agent writes the line that acquires a handle because the task needs it, and closing it is a separate step that is easy to forget, especially after a later edit replaces a with block or moves code out of a try. Nothing fails in a short test run.
Each call leaks one handle: a file descriptor, a pooled connection, a worker thread or a live timer. The process accumulates them until it hits the descriptor limit or the pool is empty, and then every request fails at once, usually hours after the deploy and with no obvious link to the change.
Example
def export_rows(path, rows):
- with open(path, "w") as out:
- for row in rows:
- out.write(format_row(row))
+ out = open(path, "w")
+ for row in rows:
+ out.write(format_row(row))
+ return len(rows)
What it detects
- Python: open(), socket.socket(), .cursor(), httpx.Client and AsyncClient, and sqlite3.connect assigned to a name with no close() or with for that name anywhere in the enclosing function.
- JavaScript and TypeScript: fs.openSync, createReadStream and createWriteStream, new Worker, net.connect, and setInterval with no matching closeSync, close, destroy, end, pipe, terminate or clearInterval.
- Go: os.Open, os.Create, http.Get and http.Post with no defer Close in the next few lines.
- Not flagged: Python with and async with, contextlib.closing, handles that are returned, yielded or stored on self or this, streams piped immediately, and unnamed handles. The one unnamed exception is setInterval, and only when clearInterval appears nowhere in the file.
What to do when it fires
Tie the release to the acquisition so it happens on every path, including errors: with open(...) in Python, defer f.Close() right after the error check in Go, and a finally block or an explicit teardown in JavaScript. For timers, keep the handle and clear it when the owning component or service stops.