Your CLI tests err == sql.ErrNoRows and now reports "lookup failed" for ids that do not exist. How do you diagnose and fix it?

## The shape of the bug A small CLI looks up one record by id and prints it. The repository runs a single-row query and returns whatever comes back; the command layer decides how to report it: ```go rec, err := repo.Find(ctx, id) if err == sql.ErrNoRows { fmt.Println("no record with that id") return nil } if err != nil { return fmt.Errorf("lookup failed: %w", err) } ``` This worked. Then someone improved the repository so its errors say which query failed, returning a new error that carries the original as its cause. Nothing in the CLI changed, nothing failed to compile, no test went red — and now a missing id exits non-zero with `lookup failed: find user 42: sql: no rows in result set`. `sql.ErrNoRows` is a sentinel: one package-level value returned by `(*sql.Row).Scan` when a single-row query selected nothing. `==` asks whether the value in your hand *is* that value. Once a layer returns a new outer error, it is not — even though the sentinel is still reachable underneath. ## Diagnosing it The symptom points straight at classification, because the *message* is right and the *branch* is wrong: the text still ends in `sql: no rows in result set`, so the information survived; only the decision went astray. That combination — correct message, wrong branch — is the signature of a broken sentinel comparison, and it is worth recognising on sight. To confirm, ask both questions at the failing branch: ```go fmt.Println(err == sql.ErrNoRows) // false fmt.Println(errors.Is(err, sql.ErrNoRows)) // true ``` When those disagree, the diagnosis is complete: the sentinel is in the chain but not on top. If you want to see the shape, walk it with `errors.Unwrap` in a loop, printing `%T` and the message at each step, until it returns nil. `%+v` on the error will not show you the structure — only the concatenated message — which is why the loop is worth writing once. A second possibility is worth ruling out: the sentinel might not be in the chain at all, because a layer rebuilt the error from its text and dropped the cause. Then `errors.Is` is also false, and the fix belongs in that layer, not in the CLI. ## Fixing it ```go rec, err := repo.Find(ctx, id) if errors.Is(err, sql.ErrNoRows) { fmt.Println("no record with that id") return nil } ``` Two further judgments belong with the fix. **Sweep, do not spot-fix.** The same `==` form is almost certainly elsewhere in the codebase, and every instance is a latent version of this bug. Grep for comparisons against sentinel values and convert them all in one change, including the ones that currently work. **Consider whether the CLI should be matching a database sentinel at all.** `sql.ErrNoRows` leaking into the command layer means the repository's abstraction is thin: every caller now has to import `database/sql` to classify a normal outcome. A common improvement is for the repository to translate it into its own condition at its boundary. That is a design call about the package surface, but the diagnosis and the immediate fix stand on their own. ## The guard Why did the existing tests pass? Because a repository test calls the repository and gets its error directly; a command test with a fake repository returns whatever the fake was told to return, which was the bare sentinel. In both, nothing wrapped, so `==` and `errors.Is` agree. The test that catches this is the one that reproduces the *assembled* shape — the sentinel with at least one layer of context on it: ```go func TestMissingRowIsReportedAsEmpty(t *testing.T) { err := fmt.Errorf("find user 42: %w", sql.ErrNoRows) if !errors.Is(err, sql.ErrNoRows) { t.Fatal("missing-row condition is no longer detectable") } } ``` Better still, apply that to the real classification helper rather than to `errors.Is` itself, so the test exercises your code: give the fake repository an error that is wrapped one layer deep and assert the CLI exits zero with the empty-result message. The general rule this leaves behind: **fakes and fixtures should return errors shaped the way production produces them.** A fake that hands back a pristine sentinel is testing a call chain that does not exist. ## Why nothing caught it earlier - The compiler is happy: both operands are of interface type `error`. - `go vet` has no check for it — this is not a type error, it is a semantic one. - The race detector, profiles and traces are all irrelevant; nothing is slow or concurrent, the program simply decided wrongly. - Code review misses it because `err == sql.ErrNoRows` reads like the obvious thing, and it *was* correct when it was written. That leaves review discipline plus a test as the only defences, which is exactly why the convention is to write `errors.Is` unconditionally rather than deciding case by case whether a chain exists today.