Bug in queries/reflect.go in which bind does not check rows.Err() prior to returning sql.ErrNoRows

[jonderry]

This can cause sql.ErrNoRows to be returned incorrectly when any error occurs before foundOne is set to true. This danger is documented for Bind, but Query.Bind does not check this. Nor does bind.

[stephenafamo]

Kindly send in a PR to fix

[marcoabreu]

We hit this bug in production and traced it to its root cause. Adding a detailed analysis that may help anyone working on a fix.

Full trace

The bug exists at three layers, but only bind() needs fixing:

Layer 1: bind() — the origin

queries/reflect.go:275-276:

foundOne := false
for rows.Next() {
    foundOne = true
    // ...
}

// BUG: does not check rows.Err() before returning sql.ErrNoRows
if bkind == kindStruct && !foundOne {
    return sql.ErrNoRows
}

Per the database/sql.Rows.Next() docs:

It returns true on success, or false if there is no next result row or an error happened while preparing it. Err should be consulted to distinguish between the two cases.

When rows.Next() returns false due to an I/O error (TCP reset, context cancellation, TLS failure, etc.), the real error is stored in rows.Err(). Since bind() never checks it, the error is misclassified as sql.ErrNoRows.

Layer 2: Bind() — doesn't compensate

if err = bind(rows, obj, structType, sliceType, bkind); err != nil {
    if innerErr := rows.Close(); innerErr != nil {
        return errors.Wrapf(err, "error on rows.Close after bind error: %+v", innerErr)
    }
    return err  // ← returns sql.ErrNoRows, never calls rows.Err()
}
// rows.Err() is checked here — but only on the success path
if err = rows.Err(); err != nil {
    return errors.Wrap(err, "error from rows in bind")
}

The rows.Err() check (line 153) is only reachable when bind() returns nil. On the error path, Bind() returns bind()'s error directly.

Layer 3: One() — strips context

The generated One() method unwraps the error to bare sql.ErrNoRows:

if errors.Is(err, sql.ErrNoRows) {
    return nil, sql.ErrNoRows
}

Making it impossible for any upstream caller to detect the real failure.

Slice binding is also affected

The slice path (kindSliceStruct, kindPtrSliceStruct) doesn't return sql.ErrNoRows, but it also doesn't check rows.Err() after the loop. A connection error mid-iteration would silently return a partial result set with no error.

Production impact

In our case, the application distinguishes "not found" (permanent, don't retry) from connection errors (transient, retry). This bug caused transient Cloud SQL connection failures to be permanently classified as "not found", silently dropping messages that should have been retried. Multiple entities were affected over several days before we traced it to this SQLBoiler code path.

Proposed fix

Check rows.Err() in bind() immediately after the loop, before any other error logic:

for rows.Next() {
    foundOne = true
    // ... existing scan logic ...
}

// Return real error if rows.Next() stopped due to failure
if err := rows.Err(); err != nil {
    return errors.Wrap(err, "failed to iterate rows")
}

if bkind == kindStruct && !foundOne {
    return sql.ErrNoRows
}

return nil

This is backwards-compatible: callers using errors.Is(err, sql.ErrNoRows) will no longer match on connection failures, which is the correct behavior. It also fixes the silent partial-result issue for slice binding.

This also addresses #1443 (same root cause, triggered by context cancellation).

Happy to submit a PR if that would be helpful.