fix(go_modules): reconcile go.sum checksums using module graph diffing

[kbukum1]

What are you trying to accomplish?

When Dependabot updates Go dependencies, Go tooling (go get, go mod tidy -e) can over-prune /go.mod checksum entries from go.sum for transitive dependencies unrelated to the update. This causes Dependabot PRs to unexpectedly remove hash entries, leading to CI failures when downstream pipelines run go mod tidy and detect a diff.

The fix captures the module dependency graph (via go mod graph) before and after the update to determine which modules actually changed. Any /go.mod checksum lines removed for unchanged modules are restored, while legitimate changes from the update are preserved.

Fixes #14872

Anything you want to highlight for special attention from reviewers?

A reusable GoModGraph helper is introduced for capturing and diffing Go module graphs. This can be used beyond this fix for any future need to understand module graph changes. The reconciliation is scoped precisely — it only restores /go.mod checksum lines for modules whose version did not change in the graph, ensuring we never interfere with legitimate dependency updates including transitive ones.

How will you know you have accomplished your goal?

• Existing go_modules specs continue to pass.
• New specs verify: unrelated checksums are restored when over-pruned, and checksums for updated dependencies are not restored.
• Users from issue Dependabot unexpectedly removes hash of go.mod from go.sum #14872 should no longer see unexpected removal of /go.mod checksum lines from go.sum.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[Copilot]

Pull request overview

This PR addresses a Go Modules updater behavior where go get / go mod tidy -e can over-prune /go.mod checksum entries from go.sum for modules unrelated to the update, causing downstream CI to re-introduce the removed lines. It introduces a module graph capture/diff helper (go mod graph) and uses it to selectively restore removed /go.mod checksum lines for unchanged modules.

Changes:

• Add GoModGraph helper to capture and diff go mod graph output.
• Capture module graphs before/after updates and reconcile go.sum by restoring over-pruned /go.mod checksum lines for unchanged modules.
• Add specs covering checksum restoration behavior and GoModGraph parsing/diffing.

Show a summary per file

File	Description
go_modules/lib/dependabot/go_modules/file_updater/go_mod_updater.rb	Capture module graphs and reconcile go.sum based on changed module paths.
go_modules/lib/dependabot/go_modules/file_updater/go_mod_graph.rb	New helper for capturing/parsing go mod graph and diffing module changes.
go_modules/spec/dependabot/go_modules/file_updater/go_mod_updater_spec.rb	New test cases for restoring over-pruned go.sum entries.
go_modules/spec/dependabot/go_modules/file_updater/go_mod_graph_spec.rb	New unit tests for GoModGraph.capture and #changed_modules.

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 3

[v-HaripriyaC]

As per our discussion, adding the approach which is a combination of fixes to make sure the issue is resolved mostly: Did anything get removed from go.sum at all?
Were the removed lines specifically /go.mod h1: lines?
Do those removed lines belong to modules that did not materially change?
Only then restore them.
in short: We reconcile because we observed specific removed checksum lines.
We use the graph only to avoid restoring lines for legitimately changed modules.

[thavaahariharangit]

@kbukum1 We need to debug this line, where the actual file update (go get lib@version) happens.

The goal is to inspect whether the output of that go get step includes gonum, since the customer reports it as missing.

go mod tidy runs after this point, so the potential side effect—if any—would come from the go get invocation itself. We need to debug that specific command.

To proceed, we’ll need the customer’s manifest and sum files so we can reproduce the behaviour accurately.

[kbukum1]

@kbukum1 We need to debug this line, where the actual file update (go get lib@version) happens.

The goal is to inspect whether the output of that go get step includes gonum, since the customer reports it as missing.

go mod tidy runs after this point, so the potential side effect—if any—would come from the go get invocation itself. We need to debug that specific command.

To proceed, we’ll need the customer’s manifest and sum files so we can reproduce the behaviour accurately.

@thavaahariharangit
As requested, I've put together a detailed root cause analysis with a local reproduction: https://github.com/dsp-testing/go-sum-repro/blob/main/ROOT_CAUSE.md

This covers the exact reproduction steps, why it's intermittent, why debugging a single go get invocation wouldn't have surfaced the issue, and why customer manifest files weren't needed — all points that were raised in your reviews. I had already explained this in our standup and across two PRs (#15094 and #15106), but hopefully having it documented in one place puts these concerns to rest.