x/build: build failures due to 410 Gone responses from symbolic-datum-552 GOPROXY
#53572
Comments
bcmills
added
Testing
|
I got very similar failures in x/tools trybots (linux and windows) on https://go.dev/cl/413578 on 2022-06-23 around 15:22 UTC. Different packages, and no x/benchmarks involved, but same 410 Gone: https://storage.googleapis.com/go-build-log/2e773a38/linux-amd64_f7fad36c.log |
I don't think so. This part of go-build is probably https://cs.opensource.google/go/x/benchmarks/+/master:sweet/harnesses/go-build.go;l=93. i.e., we are just doing a plain |
|
Change https://go.dev/cl/414396 mentions this issue: |
bcmills
changed the title
go-build failure due to 410 Gone responses from symbolic-datum-552 GOPROXY410 Gone responses from symbolic-datum-552 GOPROXY
Indeed, and here's another one building Updating the search regexp, we have: It's not clear to me whether this is a problem in the |
For golang/go#53572. Change-Id: I6a90f20d7032b3e2d3989ae7357d0340854b5f64 Reviewed-on: https://go-review.googlesource.com/c/benchmarks/+/414396 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
|
https://go.dev/ref/mod#private-module-privacy
The coordinator sets GOPROXY without a This explains why 410 causes failure. But it isn't clear to me (1) if it is intentional that we don't have a direct fallback, or (2) why this hasn't been occurring for a long time. |
|
Re 1, I think we don't have a direct fallback because, if |
|
Thanks, that makes sense. I figured that might be the case when I realized that we are just providing a reverse proxy to proxy.golang.org. cc @heschi @suzmue if they are aware of changes to the proxy that may have triggered this. One possible theory is that over time the versions of the packages we are fetching have become sufficiently unpopular globally that they are now more likely to fall out of cache in the proxy. So far, it seems the versions we have received 410 on are:
|
|
So it looks like this path is hitting (Maybe a bad interaction with some bug or outage on the module fetch path? But at that point I would expect to see something describing the fetch error, not just |
|
This is a semi-known bug in the module proxy. @suzmue should know more. |
greplogs -l -e '\[sweet\] error: build .*(?:\n.*)*410 Gone' --since=2022-01-012022-06-22T16:18:44-0fc6e7c-92c9b81/linux-amd64-perf
It's not obvious to me how the
symbolic-datum-552proxy gets populated or whether perhaps thex/benchmarks/sweetmodule dependencies are somehow non-hermetic or unstable.(attn @prattmic @mknyszek; CC @golang/release)
The text was updated successfully, but these errors were encountered: