Error return value ignored or silently discarded

An error return from an I/O, database, or side-effecting call is discarded with `_ =` or silently overwritten, so failures pass undetected.

missing-error-propagation high confidence runtime go

Error return value ignored or silently discarded

What this failure means

An error return from an I/O, database, or side-effecting call is discarded with _ = or silently overwritten, so failures pass undetected.

Diagnosis

A function returns an error that is discarded with _ = or left unchecked. Failures in I/O, database, or side-effecting operations pass silently.

Common patterns that trigger this:

  • _ = db.Exec(...) — database write result dropped
  • _ = f.Write(...) — file write error ignored
  • _, _ = someFunc() — both returns discarded in a multi-return call
  • err = nil — error forced to nil before the check

The risk is highest when the ignored call produces a side effect that the caller assumes succeeded (for example, a committed transaction, a written file, or a deleted record).

Fix steps

  1. Propagate the error to the caller — wrap it with context: return fmt.Errorf("context: %w", err).
  2. If the error genuinely cannot affect correctness, document why with a comment and log it at WARN level.
  3. Use errcheck in CI to catch ignored error returns statically.
  4. If you already run Staticcheck, treat SA4006 as a companion signal for overwritten values, but do not rely on it as the primary ignored-error check.

Validation

  • Re-run the failing workflow step.
  • Confirm the original failure signature for Error return value ignored or silently discarded is gone.

Why it matters

Silent error discard is the leading cause of undetected data corruption and hard-to-diagnose production issues. When db.Exec, tx.Commit, or file.Write returns an error and it is ignored, the application continues as if the operation succeeded, potentially leaving data in an inconsistent state with no log trail.

Prevention

  • Enable errcheck and staticcheck in the CI linting step.
  • Use a shared wrapper for common I/O operations that always checks and propagates their errors.

Try it locally

make test
rg -n _= .
go test ./...
go vet ./...

How Faultline detects it

Use faultline explain missing-error-propagation to see the full playbook.

faultline analyze build.log
faultline explain missing-error-propagation

Generated from playbooks/bundled/source/missing-error-propagation.yaml. Do not edit directly.

Try it on your own failed log

$ faultline analyze failed.log
Want this across every CI run? Faultline Teams tracks recurring failures across all your repos and surfaces patterns in a shared dashboard.