Oh! I recall we had some discussion about this in #47428 (comment)

Do we know what it's trying to restore? Given that we use vendoring, I'm wondering what module cache it would try to use outside of that. If there's none, perhaps we need to disable the cache 🤔

It also restores the go build cache (go env GOCACHE). Basically it's using the hash of go.sum file to make a cache key, so the cache is invalidated whenever go.sum changes.
I don't see any meaningful impact on the jobs execution time though. So maybe we can just disable that..

FWIW, I'm not against doing this, but perhaps only to make the action happy (as it may not bring much gain from a performance perspective otherwise?)

👍 yeah, let's bring it in then

I was also wondering if we should have a target to run it in a container instead of using the go-setup action, but I guess that may be hella slow on Windows, so probably not great.