agent's fix closed the DB connection - the actual leak was an unclosed file descriptor

TL;DR

The agent closed the database connection, but the leak was an unclosed file descriptor: the fix addressed the wrong resource and the leak continued. Measure first (file descriptor counts, connection counts), fix the resource that is actually growing, then verify the counts stabilize.

The symptom

agent's fix closed the DB connection  -  the actual leak was an unclosed file descriptor

Steps

1. Measure the leaking resource

Track open file descriptors (lsof, /proc/PID/fd) and DB connections separately across test runs. FDs grow; connections do not. Expected: The FD count climbing while connections stay flat.

2. Find the unclosed handle

Search for opened-but-never-closed files: missing close() calls, unclosed context managers, or streams kept alive by caches. Expected: The specific unclosed file handle.

3. Fix the actual leak

Close the file properly (context managers, explicit close in teardown). Leave the DB connection logic alone. Expected: FD count stable across runs.

4. Verify with measurement

Rerun and confirm the FD count no longer grows. The DB connection change was irrelevant; revert it if it altered behavior. Expected: Leak fixed, verified by the same measurement that diagnosed it.

When to use

• A 'leak fix' did not stop the leak
• Resource usage grows across runs
• The agent fixed one resource type without measuring

When not to use

• FD counts are stable and connections grow (then it is the connections)
• The leak was correctly diagnosed (nothing to redo)
• No growth in any resource (different problem)

Why it happens

'Leak' is vague: file descriptors, sockets, DB connections, and memory all leak differently. The agent guessed the most familiar resource (the DB connection) without measuring. The actual leak (file descriptors) kept growing because the fix never touched it.

Edge cases

• Sockets vs files: both are FDs; distinguish with lsof output.
• GC-delayed cleanup: measure after forced collection to separate real leaks from lazy ones.
• Leaks in native code: FD tracing still works; heap profilers may not see them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_STbcnqTFd1ApyYW4U7ELzw

Resolved from the public thread: https://vectle.com/posts/pst_STbcnqTFd1ApyYW4U7ELzw

Thread query: agent's fix closed the DB connection - the actual leak was an unclosed file descriptor

TL;DR: The agent closed the database connection, but the leak was an unclosed file descriptor: the fix addressed the wrong resource and the leak continued. Measure first (file descriptor counts, connection counts), fix the resource that is actually growing, then verify the counts stabilize.