An HTTP handler sums a column over rows from db.QueryContext and its total comes back short by a few rows on some requests, with no error logged. How do you find the cause?

## The symptom tells you where to look "Short by a few rows, sometimes, with no error anywhere" is one of the few Go database bugs with a nearly unique fingerprint. Nothing in `database/sql` throws away rows on its own. Something in the loop is ending early or skipping, and doing so without producing an error your code returns. ### Why `Next` can lie `(*sql.Rows).Next() bool` advances the cursor and returns `false` when there is nothing more to read. That covers two very different states: 1. The result set was fully consumed. This is success. 2. Iteration failed — the context was cancelled, the connection dropped, the driver hit a protocol or decode error mid-stream. This is failure. `Next` has no error return, so at the point the loop exits the two are indistinguishable. `(*sql.Rows).Err()` is the only thing that separates them: it returns the error that ended iteration, or `nil` at a clean end of data. A loop that ends with `return total, nil` instead of checking `rows.Err()` converts every mid-stream failure into a plausible-looking wrong answer. This is worse than a crash, because the result is *almost* right — a total short by a few rows is exactly the kind of number that survives review and gets reconciled against by a human weeks later. ### The three ways rows go missing **1. Unchecked `rows.Err()`.** The primary suspect, above. **2. A swallowed `Scan` error.** Inside the loop, `if err := rows.Scan(&amount); err != nil { continue }` — or a `log.Printf` with no return — skips the row and keeps going. Now a single unconvertible value quietly reduces the total. A `continue` on a `Scan` error is almost never right; the row you failed to read is data you are now silently omitting. **3. An early `break` on a condition that is not really terminal**, for example breaking out on the first zero value, or a `LIMIT` that was tuned for a smaller dataset. These are ordinary logic bugs but produce the same shape of symptom. A fourth, less common: the deferred `rows.Close()`'s error return is discarded. That error is usually redundant with `rows.Err()`, so it is the least informative of the four — but a reviewer noticing it often notices the missing `Err` check on the way. ### The cancellation case, concretely In an HTTP handler that passes `r.Context()` into `QueryContext`, a client that gives up mid-response cancels the context. `database/sql` closes the result set, `Next` returns `false`, and `rows.Err()` reports the cancellation. If nobody checks, the handler finishes computing a partial total and writes it. That explains the *intermittency* in the report: it happens only on requests that were interrupted, or that raced a connection being retired, so it never reproduces in a quiet environment and never reproduces under a single manual test. ### Reproducing it deliberately The way to turn this from a theory into a fact is an integration test against a real driver rather than a unit test with a fake. Run a query that returns many rows, cancel the context — or close the underlying connection — after the first row, and assert that the helper under test returns a **non-nil error**. A correct implementation fails the request; the buggy one returns a short total and `nil`, and the test catches it. Keep that test: it is the regression guard for a bug class that is invisible in production telemetry, because there is no error to count. ### The fix ``` var total int64 for rows.Next() { var amount int64 if err := rows.Scan(&amount); err != nil { return 0, err } total += amount } if err := rows.Err(); err != nil { return 0, err } return total, nil ``` Or, more compactly for a helper whose last statement is the return: `return total, rows.Err()`. ### Making it not happen again The compiler cannot help here — the buggy version is perfectly valid Go — and `go vet` has no check for it, so this is a review habit plus a structural one. The durable answer is to funnel reads through a small helper that owns the loop and returns `rows.Err()`, so individual call sites cannot forget. When counts and totals are business-critical, the second layer of defence is a reconciliation check that compares the aggregate against an independently computed one; the person who noticed the discrepancy in the first place was doing that by hand. ### What an interviewer is grading Not the fix — anyone can add one line. They are grading whether you *predicted* the cause from the symptom (silently wrong, not failing), whether you know that `Next` conflates two outcomes, and whether you proposed a way to prove it rather than just patching and hoping.