Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Agent-mode Go rollback and remove after `go mod tidy` drop the replace but not restore the module's go.sum lines, so the next default `go build` fails with "missing go.sum entry" while rollback exits 0 with no warning

Aberta
  • Algo errado?
#549 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
74/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
go, rust
Domínio
cli, devtools

Direção de pesquisa

Start in crates/socket-patch-core/src/patch/redirect/golang_local.rs at remove_go_redirect and follow go_mod_edit::drop_replace_entry in crates/socket-patch-core/src/vendor/go_mod_edit.rs. Compare the hosted-takeover handling in crates/socket-patch-core/src/vendor/golang.rs:364-377, then reproduce apply → go mod tidy → rollback/remove with the hermetic setup. Done means rollback and remove restore the module's go.sum entries or clearly report the required follow-up, and the default go build succeeds.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

agent:triaged bug bughunt pm:go priority:p2

[agent] Found by the scheduled Go modules bug-hunt routine (ledger #317).

Summary

In agent mode, apply points the patched module at .socket/go-patches/<module>@<version>/ with a directory replace. Go doesn't need go.sum lines for a directory replace, so go mod tidy removes the original module's h1: lines from go.sum. docs/ecosystems.md says "the wiring survives go mod tidy", so running tidy after apply is a supported workflow.

rollback (and remove <purl>) then drops the replace and the copy but leaves go.sum as tidy left it. The result is a go.mod that requires the module with no go.sum entry. The next go build with default flags (-mod=readonly) fails with missing go.sum entry for module providing package …. Rollback still reports status: success with warnings: [].

Impact

After a routine socket-patch rollback or remove, every CI build and every fresh go build/go test is red until someone runs go mod tidy or go get by hand. Nothing in the output says this is needed. Other paths already handle this:

  • The hosted leg re-resolves and restores the original module's go.sum lines.
  • The hosted→vendored takeover warns that go mod tidy will be needed after vendor --revert (vendor/golang.rs ~L364).

The agent leg does neither.

Repro (hermetic, Linux, go 1.24.7)

SP=/path/to/target/release/socket-patch
W=$(mktemp -d); M=example.com/upstream; V=v1.0.0
mkdir -p $W/stage/$M@$V $W/proxy/$M/@v $W/c/.socket/blobs
printf 'module %s\n\ngo 1.21\n' $M > $W/stage/$M@$V/go.mod
printf 'package upstream\n\nfunc Greeting() string { return "PRISTINE" }\n' > $W/stage/$M@$V/lib.go
printf 'package upstream\n\nfunc Greeting() string { return "PATCHED" }\n' > $W/patched.go
echo "{\"Version\":\"$V\"}" > $W/proxy/$M/@v/$V.info; cp $W/stage/$M@$V/go.mod $W/proxy/$M/@v/$V.mod
(cd $W/stage && zip -qrD $W/proxy/$M/@v/$V.zip $M@$V)
export GOMODCACHE=$W/modcache GOPROXY=file://$W/proxy GOSUMDB=off GOTOOLCHAIN=local
cd $W/c
printf 'module example.com/consumer\n\ngo 1.21\n\nrequire %s %s\n' $M $V > go.mod
printf 'package main\n\nimport (\n\t"fmt"\n\t"%s"\n)\n\nfunc main() { fmt.Println("OUT:", upstream.Greeting()) }\n' $M > main.go
go mod download $M@$V && go mod tidy            # go.sum: 2 lines
gsha(){ python3 -c "import hashlib,sys;d=open(sys.argv[1],'rb').read();print(hashlib.sha256(b'blob %d\0'%len(d)+d).hexdigest())" "$1"; }
B=$(gsha $W/stage/$M@$V/lib.go); A=$(gsha $W/patched.go); cp $W/patched.go .socket/blobs/$A
cat > .socket/manifest.json <<J
{"patches":{"pkg:golang/$M@$V":{"uuid":"4d5e6f70-8192-4a1b-8c2d-0123456789ab","exportedAt":"t","files":{"lib.go":{"beforeHash":"$B","afterHash":"$A"}},"vulnerabilities":{},"description":"","license":"","tier":""}},"setup":{"manual":["golang"]}}
J
$SP apply                 # exit 0, replace written
go mod tidy               # supported per docs; go.sum is now empty
go build -o /dev/null .   # OK (PATCHED)
$SP rollback              # exit 0, "Rolled back packages: pkg:golang/example.com/[email protected]"
go build -o /dev/null .   # exit 1: main.go:5:2: missing go.sum entry for module providing package example.com/upstream

$SP remove pkg:golang/example.com/[email protected] instead of rollback gives the same result. Without the go mod tidy step, both pass (go.sum keeps its 2 lines).

Expected vs actual

  • Expected: CLI_CONTRACT.md "Rollback command contract (v5.0)" says a bare rollback "restores the SYSTEM to unpatched". docs/ecosystems.md "Go: directory replaces and go.sum" says the wiring "survives go mod tidy". So after apply → tidy → rollback, the project should build exactly as it did before apply. That means either restoring the module's h1: and /go.mod h1: lines (as the hosted leg does) or, at minimum, a warning plus a non-silent outcome telling the user to run go mod tidy.
  • Actual: go.mod's require is left with no go.sum lines. Rollback/remove exit 0 with warnings: [] (--json), and the next default go build fails.

Matrix (Linux; each cell run 2× on go 1.24.7, 1× on the others)

go apply → rollback (no tidy) apply → tidy → rollback apply → tidy → remove
1.22.12 pass fail fail
1.24.7 pass fail fail
1.26.8 pass fail fail
macOS / Windows untested (probe branches currently blocked) untested untested

Vendored mode (vendor --revert after tidy) is untested here: it needs the mock patch service. The same drop-without-go.sum path looks likely.

Tested on main 61cfb9b (CLI 4.0.0). There have been no Go code changes since 4.0.0, so this isn't a regression in the 4.x line.

Suspect code

  • crates/socket-patch-core/src/patch/redirect/golang_local.rs:316 (remove_go_redirect) only calls go_mod_edit::drop_replace_entry (crates/socket-patch-core/src/vendor/go_mod_edit.rs:193) and removes the copy. go.sum is never reconciled and no warning is raised. Compare the hosted-takeover warning at crates/socket-patch-core/src/vendor/golang.rs:364-377.
Linguagem predominante
Rust
Estrelas
8
Forks
0
Merge médio
1d 7min
PRs com merge (30d)
178

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de SocketDev/socket-patch

Todas as issues de SocketDev/socket-patch

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.