-
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
x/net/http2: TestUnreadFlowControlReturned_Server failures due to INTERNAL_ERROR since 2022-03-15 #52051
Comments
This has also happened on a https://build.golang.org/log/ebd81abf53025263ed94ef3462193b7efc319315 This is the only open bug for this problem I'm finding. @bcmills Do you think it's better to expand the scope of this one to be non-Plan9 specific or file a separate tracking one for |
The output in the test log looks exactly the same to me, so I'd be inclined to expand the scope. The fact that there are no GOOS or GOARCH elements in common suggests that this is a platform-independent bug (quite possibly timing related). |
Yep, here's the problem: another arbitrary timeout. Should be a trivial fix, so I'll go ahead and mail it. |
Change https://go.dev/cl/410096 mentions this issue: |
Moving to the Go 1.19 milestone since |
I think Go1.19 milestone is fine, just note that only the http2 package code is bundled into the standard library and not its tests, so nothing in the main repo will change when the next dependency update is performed. |
If the test gets completely stuck at these points, we will want a goroutine dump in order to debug the hang, which log.Fatalf will not produce (but a test timeout will). If the test does not get completely stuck (as on a slow or overloaded builder), then we should let it continue to run until the overall test timeout, which (unlike hard-coded constants) should already take the speed of the builder into account. As a side-effect, this also moves some t.Fatalf calls out of background goroutines and into the main test-function goroutines where they belong (see golang/go#24678). Fixes golang/go#52051. Change-Id: I37504081e6fdf0b4c244305fc83c575e30b7b453 Reviewed-on: https://go-review.googlesource.com/c/net/+/410096 Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Bryan Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]>
If the test gets completely stuck at these points, we will want a goroutine dump in order to debug the hang, which log.Fatalf will not produce (but a test timeout will). If the test does not get completely stuck (as on a slow or overloaded builder), then we should let it continue to run until the overall test timeout, which (unlike hard-coded constants) should already take the speed of the builder into account. As a side-effect, this also moves some t.Fatalf calls out of background goroutines and into the main test-function goroutines where they belong (see golang/go#24678). Fixes golang/go#52051. Change-Id: I37504081e6fdf0b4c244305fc83c575e30b7b453 Reviewed-on: https://go-review.googlesource.com/c/net/+/410096 Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Bryan Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]>
greplogs --dashboard -md -l -e 'FAIL: TestUnreadFlowControlReturned_.*' --since=2022-01-01
2022-03-30T02:16:17-de3da57-d1060d8/plan9-386-0intro
2022-03-25T01:24:44-27dd868-8ab42a9/plan9-386-0intro
2022-03-18T19:32:40-27dd868-a682a5c/plan9-386-0intro
2022-03-18T16:57:07-27dd868-0a49f70/plan9-386-0intro
2022-03-15T01:00:36-27dd868-44a0da4/plan9-386-0intro
(attn @0intro; CC @neild)
See previously #49645.
The text was updated successfully, but these errors were encountered: