SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Go New Added 10 September 2026

go: updates to go.mod needed; to update it: go mod tidy

Go stopped editing go.mod as a side effect of build commands in 1.16, so a missing or stale requirement is now reported instead of quietly added. It usually appears in CI first, because a local run had already written the change into go.mod that nobody committed.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Do what it asks, then commit both files
go mod tidy
git status go.mod go.sum

# See what tidy would change before running it
go mod tidy -diff

# CI should fail on a dirty tree rather than fix it silently
go mod tidy
git diff --exit-code go.mod go.sum

# Build without any edits, to reproduce the CI behaviour locally
go build -mod=readonly ./...

# Vendored projects need the vendor tree refreshed too
go mod vendor && go build -mod=vendor ./...

How to diagnose Go errors

Go's runtime is unusually good at telling you what went wrong. concurrent map writes and all goroutines are asleep - deadlock! are precise diagnoses rather than vague crashes. The recurring themes are nil zero values that need explicit initialisation (maps, channels, pointers inside interfaces), unsynchronised shared state, and contexts that are cancelled upstream.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Run tests and, where possible, production builds under the race detector: go test -race ./.... It finds data races that are invisible under normal execution.
  2. Read the full panic output. Go prints every goroutine's stack, and the one that matters is usually not the first.
  3. For context canceled, walk up the call chain to find who cancelled: a client disconnect, a timeout, or a parent context that went out of scope are the three sources.
  4. Distinguish a nil interface from an interface holding a nil pointer. var p *T = nil; var i I = p makes i != nil, which is the cause of most "interface conversion: interface is nil" surprises.
  5. Use go tool pprof and runtime.NumGoroutine() to find goroutine leaks. A count that only ever grows means something is never returning.

Tools worth reaching for

  • go test -race
  • go vet
  • go tool pprof
  • GODEBUG=gctrace=1
  • delve (dlv)

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

go.dev

Related Go errors

See all 19 Go errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.