-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: frequent HTTP2 INTERNAL_ERROR errors during module zip download since 2021-10-06 #51323
Comments
From logs, it's also happened for github.com dependencies such as Downloading happens with I've learned that INTERNAL_ERROR refers to an HTTP/2 error code that is described as "Implementation fault", but it's not clear to me if the server or client is at fault. CC @neild. |
Recently, we've encountered this fairly frequently (a few times per day) in GitHub Actions, usually for github.com URLs. For example:
|
The best explanation I have for this is some kind of infrequent incompatibility between the Go HTTP libraries and the Google front end servers. |
It occurs to me that this could be related to #49645 (CC @neild), although the timeline doesn't quite match up because the fix for that landed Nov. 17.
2022-03-29T15:43:06-e96d8cf-ae9ce82/windows-amd64-longtest |
Is there any update on this issue! Experiencing too frequently |
|
This could possibly be a duplicate of #36759 (reported as a regression Jan. 2020). |
There are various other error codes to tell the client that it is misbehaving, such as So whatever is doing the module zip download is claiming that it's unhealthy. It's not inconceivable that this is somehow the result of a Maybe if we can reproduce the failure with GODEBUG=http2debug=2 enabled we might see something that helps indicate the source of the problem, but at the moment my suspicion is that the problem lies on the remote end of the connection. |
googleapis/google-cloud-go#784 seems like the same issue. From 2017, eventual "fix" was to notice INTERNAL_ERROR and retry the read. |
The other end of the connection here is the GFEs; should we try to escalate to them internally? |
Yeah, I think so. The possibilities I see are:
At the same time, perhaps we should have a retry loop on module downloads. Connections break for various other reasons; doesn't seem like it would hurt to retry when they do. |
Any idea how to solve this? Getting the following error when running /hpath/to/go/pkg/mod/golang.org/x/[email protected]/internal/lsp/source/hover.go:23:2: golang.org/x/[email protected]: stream error: stream ID 9; INTERNAL_ERROR; received from peer |
@neild What is the current status here? This issue is currently in the 1.19 milestone. Should it move to 1.20? To Backlog? Thanks. |
Our current belief is that the root cause is the GFE sending an This is not an Whatever tools are using I think it's okay to move this to the 1.20 milestone. |
`handleEvent` was handling the an `error` type by printing something, but then not continuing to raise the error. This means that in a stream error, particuarly of type INTERNAL_ERROR, the backoff/retry mechanism never took place as the return was `nil` and the agent just stopped. The problem is particularly relevant with Google Load Balancers and their handling of http2/websocket long lived connections: golang/go#51323 --------- Co-authored-by: Louis Garman <[email protected]>
Found new dashboard test flakes for:
2023-08-06 13:51 linux-riscv64-unmatched telemetry@6b1207f8 go@460dc37c x/telemetry/godev/internal/storage [build] (log)
2023-08-28 22:24 linux-riscv64-unmatched pkgsite@ad6c6394 go@626a3cd9 (log)
2023-08-30 14:09 darwin-amd64-11_0 build@762ea330 go@a8d45a72 (log)2023-08-30 16:14 netbsd-arm-bsiegert telemetry@03a44786 go@06df3292 (log)
2023-09-10 18:25 netbsd-arm64-bsiegert crypto@3f0842a4 go@d110d7c4 (log) |
Found new dashboard test flakes for:
2023-09-19 17:00 darwin-amd64-13 build@c8fdba98 go@2b462646 [build] (log)
|
Found new dashboard test flakes for:
2023-09-08 20:30 linux-riscv64-unmatched pkgsite@8025830b go@bda5e6c3 (log)
2023-09-19 20:58 darwin-amd64-nocgo pkgsite@14233af4 go@bf5d8c02 (log)
|
Change https://go.dev/cl/532035 mentions this issue: |
Found new dashboard test flakes for:
2023-09-25 14:46 linux-s390x-ibm benchmarks@1082dde5 go@e47cab13 (log)
|
Found new dashboard test flakes for:
2023-10-25 13:59 netbsd-arm-bsiegert telemetry@5ab6b58d go@0046c141 (log)
|
CL 233437 added a redactedURL field to proxyRepo, a struct that already had a field named 'url'. Neither fields were documented, so the similar names suggest the most natural interpretation that proxyRepo.redactedURL is equivalent to proxyRepo.url.Redacted() rather than something else. That's possibly why it was joined with the module version in CL 406675. It turns out the two URLs differ in more than just redaction: one is the base proxy URL with (escaped) module path joined, the other is just the base proxy URL, in redacted form. Document and rename the fields to make the distinction more clear, and include all 3 of base module proxy URL + module path + module version in the reported URL, rather than just the first and third bits as seen in the errors at https://go.dev/issue/51323#issuecomment-1735812250. For #51323. Updates #38680. Updates #52727. Change-Id: Ib4b134b548adeec826ee88fe51a2cf580fde0516 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/532035 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
Found new dashboard test flakes for:
2023-11-10 21:13 solaris-amd64-oraclerel pkgsite@545ce2ad go@31f0af1e (log)
|
Found new dashboard test flakes for:
2023-11-14 16:31 linux-riscv64-unmatched telemetry@69313e64 go@1c15291f (log)
|
Found new dashboard test flakes for:
2023-11-21 19:04 windows-amd64-longtest go@ebca52ee cmd/go.TestScript (log)
2023-11-21 19:26 linux-386-longtest go@b3b44244 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-11-27 16:49 darwin-amd64-longtest go@6317fb41 cmd/go.TestScript (log)
|
Found new dashboard test flakes for:
2023-11-30 03:00 linux-riscv64-unmatched pkgsite@9f20944f go@b4fa5b16 (log)
|
Found new dashboard test flakes for:
2023-11-27 18:10 netbsd-arm64-bsiegert perf@b5375226 go@bda1ef13 (log)
|
Found new dashboard test flakes for:
2024-03-06 21:06 linux-riscv64-unmatched telemetry@d5a85b27 go@90d24b4f (log)
|
I am facing the below errors Any root cause for this? |
In That is, the server you are talking to sent back an |
is server sending RST_STREAM incase of any internal error introduced in latest go version or was it existing in earlier versions because when we were using x/net/v0.0.0-20211029224645-99673261e6eb this behaviour was not coming and when we updated it to x/net/v0.19 for fortify fixes,we are encountering this error @neild |
I'm sorry, but I don't have enough details to attempt to answer that question. The error is coming from the remote server. Did you update your server to a newer version of
|
The builders are seeing a lot of
INTERNAL_ERROR
results since 2021-10-06, typically forgoogle.golang.org/protobuf
but sometimes for othergolang.org
paths as well.This may be related to #50541, which saw an uptick in errors from
go.googlesource.com
in about the same timeframe.CC @golang/release
greplogs --dashboard -md -l -e 'golang\.org/[^@]+@v\d+\.\d+\.\d+[a-z0-9-.]*: stream error: stream ID \d+; INTERNAL_ERROR; received from peer' --since=2021-01-01
2022-02-19T16:23:54-3962a08-0261fa6/dragonfly-amd64
2022-02-10T22:36:44-59536be-0a6cf87/linux-amd64-wsl
2022-02-09T18:09:24-9862752-6a70ee2/darwin-arm64-11_0-toothrot
2022-02-09T16:29:28-dad3315-0a6cf87/darwin-arm64-12_0-toothrot
2022-02-09T16:29:28-095f870-0a6cf87/darwin-arm64-12_0-toothrot
2022-02-08T17:01:10-9b156ee-ef06a5f/plan9-amd64-0intro
2022-02-08T16:42:58-ac99473-e2277c8/darwin-arm64-12_0-toothrot
2022-02-03T19:55:40-cd36cc0-896df42/plan9-amd64-0intro
2022-01-25T22:56:45-c20fd7c-6eb58cd/plan9-amd64-0intro
2022-01-24T21:27:33-6944b10-671e115/plan9-amd64-0intro
2022-01-24T21:27:33-5e0467b-671e115/plan9-amd64-0intro
2022-01-14T16:41:18-4bd3f69-b41185c/plan9-386-0intro
2022-01-07T02:32:39-e83268e-2bb7f6b/linux-amd64-wsl
2022-01-05T22:15:55-43762dc-a845a56/darwin-arm64-12_0-toothrot
2022-01-03T23:45:12-be6af36-95b240b/plan9-amd64-0intro
2022-01-02T14:27:43-6944b10-c886143/plan9-amd64-0intro
2021-12-15T20:26:19-be6af36-07ed86c/darwin-arm64-12_0-toothrot
2021-12-14T18:18:45-ecdc095-becaeea/plan9-arm
2021-12-14T01:48:22-6944b10-1afa432/plan9-amd64-0intro
2021-11-10T19:35:55-03971e3-b954f58/darwin-arm64-11_0-toothrot
2021-10-28T14:25:03-103d89b-a3bb28e/darwin-amd64-10_15
2021-10-26T11:58:05-d418f37-1e2820a/openbsd-arm64-jsing
2021-10-14T15:16:55-a66eb64-ad99d88/linux-amd64-wsl
2021-10-14T01:51:22-e13a265-276fb27/windows-arm64-10
2021-10-13T00:11:47-281050f-4fb2e1c/darwin-amd64-11_0
2021-10-11T20:46:14-089bfa5-7023535/darwin-amd64-11_0
2021-10-07T20:37:43-86761ae-ef2ebbe/darwin-arm64-11_0-toothrot
2021-10-07T20:37:43-59d4e92-ef2ebbe/darwin-arm64-11_0-toothrot
2021-10-06T18:44:56-40a54f1-195945a/darwin-amd64-nocgo
The text was updated successfully, but these errors were encountered: