eng-cleanup-failure-paths

Build an acquisition matrix listing every fallible resource the function acquires, then walk backward from every exit (success, error, cancellation, panic) to confirm each resource is released or ownership is transferred. Pair each acquisition with its canonical cleanup, such as defer cancel() after context.WithTimeout.

Inject a failing dependency through an interface, then assert the resource is actually released, not just that a cleanup method was called. For subprocesses, cancel the parent context mid-flight and assert the process group exits within a timeout; for HTTP, force a 5xx and verify the body is drained and closed.

Yes, always drain the body even on non-2xx responses, otherwise the connection is poisoned for keep-alive reuse. Account for both the io.Copy drain error and the Close error, and do not double-drain when an SSE reader already handles it.

Skip it for pure transformations, read-only helpers, and test-only code that acquire no fallible resources. The audit targets functions that acquire, register, start, claim, lease, or open more than one resource before returning.

More than roughly six defers signals the function owns too many resources and cannot prove cleanup on every exit. Split ownership into smaller helpers, push cleanup to the caller via an opener-closer pair, or return a cleanup func() callback before adding more defers.