At this failure rate, this looks to me like a release-blocker via #11811. The test should either be fixed or skipped on the affected builders.

Looking at the test, I see at least three problems with the timeout strategy:

1. If the server actually wedges, its output logs (and, critically, its goroutine dump) is not logged anywhere. (The process is killed with cmd.Process.Kill instead of a signal that would give it the opportunity to dump goroutines.)

2. The deadlines are hard-coded, inconsistently, without comments explaining why those deadlines should be fundamental. (One server gets only 15s, while the others get two minutes each.)

Probably for this issue we can just fix (2), although it would be nice to address (1) as well.

Looking at this further, the failures are always in TestWeb/GOPATH. Perhaps we should just skip that subtest in -short mode, since at this point most users are in module mode anyway.

TestWeb/GOPATH takes less than a second on my workstation. I think this is uncovering a real bug in either godoc or the test itself.`

cc @dmitshur

Change https://golang.org/cl/373005 mentions this issue: internal/moreexec: add a utility package for manipulating os/exec.Cmd

Change https://golang.org/cl/377835 mentions this issue: internal/testenv: add a Command function that replaces exec.Command

Change https://golang.org/cl/377836 mentions this issue: cmd/godoc: streamline subprocesses

The test needs better diagnostics. Proposal #50436 is at the bottom of this yak stack, but in the meantime we can polyfill the needed API into an internal package.

Intriguingly, the dragonfly-amd64 failures are no longer occurring after the builder was upgraded for #50538 (thanks, @tuxillo!).

We should still add better failure diagnostics to this test, but since it is no longer failing on the builders it won't mask other regressions, and doesn't need to be a release-blocker.

Now seen on windows-arm64-11 too, so this appears to be completely platform-independent.

greplogs --dashboard -md -l -e 'FAIL: TestWeb .*\n\s+.*\n\s+.*server failed to respond' --since=2022-01-21

2022-02-17T17:38:22-411d040-eaf0405/windows-arm64-11

greplogs --dashboard -md -l -e 'FAIL: TestWeb .*\n\s+.*\n\s+.*server failed to respond' --since=2022-02-24

2022-03-02T11:33:18-ffa170d-fd2e1e7/dragonfly-amd64
2022-03-01T16:32:20-fb3622a-2199841/darwin-amd64-11_0

Marking as release-blocker for Go 1.19 due to the recent failure on the darwin-amd64-11_0 builder. (darwin/amd64 is a first class port.)

Lots of these on dragonfly-amd64 and windows-arm64-11, and a few on other ports too.

greplogs --dashboard -md -l -e 'FAIL: TestWeb .*\n\s+.*\n\s+.*server failed to respond' --since=2022-03-03

Change https://go.dev/cl/403534 mentions this issue: cmd/godoc: skip TestWeb if waitForServerReady fails

Change https://go.dev/cl/403849 mentions this issue: cmd/godoc: expand skips in TestWeb

This test now has skips for these failure modes, so it is no longer a release-blocker.

Hello Team,

I am facing issue mentioned below

--- FAIL: TestWeb (7.99s)
--- FAIL: TestWeb/GOPATH (1.44s)
godoc_test.go:423: GET http://127.0.0.1:46541/src/fmt/: wanted substring "scan_test.go" in body
godoc_test.go:446: GET http://127.0.0.1:46541/src/fmt/: got:
Let me know if there is any progress/solution?

Using x/tools/internal/testenv CL 50014 should produce better diagnostics in case of hang. If that exposes any other failure modes we can handle those as separate issues.