Will It Vibe?sql.Rows never closed
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
The *sql.Rows returned by a Query/QueryContext call has no Close() found nearby, so the underlying database connection is not returned to the pool until the garbage collector finalizes it, which can exhaust the pool under load.
Why it matters
The *sql.Rows returned by Query holds an underlying database connection checked out from the pool for as long as the Rows object is open. If nothing calls Close() on it (directly or via defer), that connection is not returned to the pool until Go's garbage collector happens to finalize the Rows value, which is not deterministic and can be much later than you expect; under real load this shows up as the connection pool slowly running out of available connections.
How to fix it
Call defer rows.Close() immediately after checking the error from Query, before you start iterating with rows.Next(). Close is safe to call even after Next() has already returned false, so deferring it right after the error check is always correct and easy to audit.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo