gomodcache info files vs proxy.golang.org

[Brad Fitzpatrick]

I'm not sure whether this is a bug. But it's a mystery. Maybe somebody has a clue...

I noticed that proxy.golang.org info files can be served in a different field order than expected by cmd/go.

e.g.

$ curl https://proxy.golang.org/github.com/google/uuid/@v/v1.6.0.info
{"Version":"v1.6.0","Time":"2024-01-23T18:54:04Z","Origin":{"VCS":"git","URL":"https://github.com/google/uuid","Ref":"refs/tags/v1.6.0","Hash":"0f11ee6918f41a04c201eceeadf612a377bc7fbc"}}

Note that the Origin's Ref comes before the Hash.

But if I `go get` it, it ends up like:

$ cat $(go env GOMODCACHE)/cache/download/github.com/google/uuid/@v/v1.6.0.info

{"Version":"v1.6.0","Time":"2024-01-23T18:54:04Z","Origin":{"VCS":"git","URL":"https://github.com/google/uuid","Hash":"0f11ee6918f41a04c201eceeadf612a377bc7fbc","Ref":"refs/tags/v1.6.0"}}

... notice the Hash comes first, and then the Ref.

If I preload a GOMODCACHE filesystem with the files from proxy.golang.org, then it triggers this code in cmd/go/internal/modefetch's func readDiskStats...

 // The disk might have stale .info files that have Name and Short fields set.

// We want to canonicalize to .info files with those fields omitted.

// Remarshal and update the cache file if needed.

data2, err := json.Marshal(info)

if err == nil && !bytes.Equal(data2, data) {

    writeDiskCache(ctx, file, data)

}

return file, info, nil

Go gets unhappy the fields aren't bytewise identical and tries to "fix" the cache. (despite not having those Name or Short fields on disk that the comment says was the motivation)

But in my case, the GOMODCACHE is a read-only filesystem and it fails, which is okay, because it's ignoring the error, but my filesystem sees the attempt, which alerted me.

Anybody know any history here?

Thanks!

Brad

[Dmitri Shuralyov]

If you look at go.dev/cl/543155, the order of fields in codehost.Origin changed such that Hash comes before Ref. That CL landed in late 2023 and got released as part of Go 1.22.0 in early 2024. The timing of when version v1.6.0 of the uuid module was cached also lines up. If that's not a red herring, perhaps it plays part in in reducing the mystery in what you reported.