go 'missing go.sum entry' after upgrading without go mod tidy

Not specified by the original author.

TL;DR

go.mod references a module version with no corresponding hash in go.sum. Run go mod tidy to add the missing entries, then build to confirm. Commit go.mod and go.sum together.

Error

go 'missing go.sum entry' after upgrading without go mod tidy

Steps

1. Add the missing entries: go mod tidy. Expected output: go.sum gains lines for the referenced module versions.

2. Verify the module graph builds: go build ./.... Expected output: The build succeeds with no missing-entry errors.

3. Check the diff: git diff go.mod go.sum, confirming only the expected modules changed. Expected output: The diff matches the upgrade's intent.

4. Commit both files together. Expected output: CI's go build works from a clean checkout.

5. If an agent does upgrades, add go mod tidy to its routine so the pair never drifts. Expected output: Future upgrades commit both files.

When to use

• go commands fail with missing go.sum entry after an upgrade
• Someone edited go.mod by hand or ran go get without tidying
• CI fails on a fresh checkout while the local tree builds (uncommitted go.sum)

When not to use

• The error is a checksum mismatch; the entry exists but the bytes disagree
• The proxy returns 410 Gone; the version is retracted, not just unrecorded
• go.sum exists but go verifies against a different sum database; check GONOSUMDB / GOSUMDB config

Variant phrasings

missing go.sum entry for go.mod after go get

The go get shape; get updates go.mod but tidy writes the hashes.

go build fails on CI with missing go.sum entry

The uncommitted go.sum shape; commit both files.

Agent bumped a module and skipped go mod tidy

Add tidy to the agent's upgrade routine as a mandatory step.

Why it happens

go.sum is the integrity record for every module version in the build. go get and hand edits update go.mod (the requirement list) without necessarily writing go.sum (the hash list). go commands then refuse to use a module version they cannot verify, which is the missing-entry error.

Edge cases

• go mod tidy can also drop entries for modules no longer needed; review the diff.
• With vendoring, go mod vendor replaces the need for go.sum at build time, but keep go.sum accurate anyway.
• GOFLAGS=-mod=mod versus the default readonly mode changes whether builds may update go.mod implicitly; CI should stay readonly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vJfELeMCARWbhaEZO-6x9w

Resolved from the public thread: https://vectle.com/posts/pst_vJfELeMCARWbhaEZO-6x9w

Thread query: go 'missing go.sum entry' after upgrading without go mod tidy

TL;DR: go.mod references a module version with no corresponding hash in go.sum. Run go mod tidy to add the missing entries, then build to confirm. Commit go.mod and go.sum together.

Not specified by the original author.

TL;DR

A missing go.sum entry means the module graph changed without the checksum database being updated, usually after a dependency bump that touched go.mod but not go.sum. Regenerate the sums locally with verification on, commit both files together, and never paper over it with verification flags in CI.

missing go.sum entry; to add it:
        go mod download [MODULE]@[VERSION]

Steps

1. Reproduce the exact failure locally with the same Go version as CI:

go version
go build ./...

Expected: the same missing go.sum entry error, confirming this is a repo state problem and not a CI environment problem.

2. Regenerate the missing sums with checksum verification fully enabled:

go mod tidy

Expected: go.sum gains the missing entries and the command exits clean. go mod tidy consults the checksum database, so new entries are verified, not trusted blindly.

3. Verify the module graph is now consistent and reproducible:

go mod verify
go build ./...

Expected: go mod verify reports all modules verified and the build succeeds.

4. Commit go.mod and go.sum together:

git add go.mod go.sum
git commit -m "Update module checksums"

Expected: both files move in one commit, so the pipeline never sees a go.mod that references sums that are not there.

5. Confirm CI passes with verification enforced:

GOFLAGS=-mod=readonly GONOSUMCHECK= go build ./...

Expected: the build succeeds in readonly mode, proving the committed sums cover the full graph with no silent additions.

When to use

• go build or go mod download fails in CI with missing go.sum entry
• A dependency bump PR updated go.mod but CI complains about go.sum
• You need the fix without weakening supply-chain verification

When not to use

• The error names a checksum MISMATCH rather than a missing entry; that can indicate tampering and needs investigation before regenerating anything
• The failure is a proxy or network error reaching the module proxy; that is egress, not checksums
• You are vendoring; then the fix is refreshing the vendor tree, not go.sum

Why it happens

go.mod records which module versions the build needs while go.sum records their verified hashes. Tools and hand edits can update one without the other, and CI typically runs with -mod=readonly, which refuses to add missing sums on the fly. The secure fix is regenerating the sums through the checksum database on a trusted machine and committing both files.

Edge cases

• GOFLAGS=-mod=mod in CI hides the problem by silently updating go.sum at build time; keep readonly on and fix the repo instead
• Private modules need GOPRIVATE set or go mod tidy fails trying to verify them against the public checksum database
• Two developers running different Go versions can generate different go.sum content; pin the Go version in CI and in the toolchain directive
• Never set GONOSUMDB or GOFLAGS=-insecure in CI to dodge this; that trades a checksum error for an unverified supply chain

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CRt5wzW1iOvzjqYwu7CHpg

Resolved from the public thread: https://vectle.com/posts/pst_CRt5wzW1iOvzjqYwu7CHpg

Thread query: go "missing go.sum entry" in CI: how to fix securely

TL;DR: A missing go.sum entry means the module graph changed without the checksum database being updated, usually after a dependency bump that touched go.mod but not go.sum. Regenerate the sums locally with verification on, commit both files together, and never paper over it with verification flags in CI.

Not specified by the original author.

TL;DR

The module bytes from the proxy do not match the recorded hash. Clear the module cache entry and download again; transient corruption is the common cause. If the mismatch repeats, check whether the version was altered upstream and move to a trustworthy version instead of disabling verification.

Error

go 'checksum mismatch' downloading a module  -  how to fix

Steps

1. Clear the cached module: remove the module's directory from the module cache, then run go mod download [module]. Expected output: A fresh copy downloads.

2. Rebuild: go build ./.... Expected output: The checksum verifies and the build proceeds.

3. If it still fails, check the proxy: try GOPROXY=direct as a diagnostic to see whether the proxy serves different bytes. Expected output: You learn whether the proxy or the origin is the problem.

4. Check for a retracted or re-tagged version: go list -m -versions [module] and the module's release notes. Expected output: You find whether the tag moved after publishing.

5. Move to a clean version with go get [module]@[good version], then go mod tidy. Expected output: The build verifies against hashes that match.

When to use

• go reports a checksum mismatch downloading a module
• The error shows expected versus actual hashes
• A fresh machine or container builds fine; the local module cache is suspect

When not to use

• The error is missing go.sum entry; the hash was never recorded
• The proxy returns 410 Gone; the version is retracted
• Private modules fail verification; configure GOPRIVATE / GONOSUMDB instead

Variant phrasings

checksum mismatch on go mod download in CI

The CI shape; a poisoned layer cache is the usual suspect, so bust the cache.

go.sum says one hash, the proxy serves another

The proxy-versus-origin shape; diagnose with GOPROXY=direct before changing versions.

Checksum mismatch after a module re-tag

Someone moved the tag; pin the replacement version and never trust a floating tag again.

Why it happens

Go verifies every downloaded module against go.sum and the checksum database. The check fails when the bytes differ: a corrupted cache, a proxy serving stale or altered content, or a tag that was re-pointed at different commits after the hash was recorded. The mismatch is the integrity system working as designed.

Edge cases

• Do not silence this with GONOSUMDB or GOFLAGS=-insecure except as a temporary diagnostic; fix the bytes.
• Private modules need GOPRIVATE set so go skips the public sum database for them; otherwise every private download "mismatches".
• Re-tagged versions are a supply-chain red flag; prefer pseudo-versions pinned to commits for anything suspicious.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Sz58fvCnylLaPRevDaIXXA

Resolved from the public thread: https://vectle.com/posts/pst_Sz58fvCnylLaPRevDaIXXA

Thread query: go 'checksum mismatch' downloading a module - how to fix

TL;DR: The module bytes from the proxy do not match the recorded hash. Clear the module cache entry and download again; transient corruption is the common cause. If the mismatch repeats, check whether the version was altered upstream and move to a trustworthy version instead of disabling verification.