Golang x/build: test failures are hard to discover

There has been a recent regression in the builder UI. Take this flake for example: if you click through to the log, there is no useful information besides FAIL: TestFoo; the stderr output has been removed. If you then click through (and crucially, know to do this) to the test JSON output, you find the name of the failing test, buried among thousands of lines of working-as-intended JSON framing information.

The primary stderr log should continue to show all of stderr.

Comment From: gabyhelp

Related Issues

• x/build/cmd/coordinator: failures are sometimes missing error output #39349 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Comment From: cagedmantis

@golang/release

Comment From: dmitshur

Issue #74323 might be relevant here.

It appears that the reason the package golang.org/x/tools/gopls/internal/test/marker tests are reported as failed is because of the data race that came up during the execution of the Test/mcptools/symbol_references.txt test in that package. (I haven't verified this, though.)

The output did correctly get associated with that test in ResultDB, and it is visible there:

https://ci.chromium.org/ui/p/golang/builders/ci/x_tools-go1.23-linux-arm64-race/b8709894442579874513/test-results?q=ExactID%3Agolang.org%2Fx%2Ftools%2Fgopls%2Finternal%2Ftest%2Fmarker.Test%2Fmcptools%2Fsymbol_references.txt+VHash%3Ad36e69d8e6dd20fb

However, is is quite hard to discover that particular test because the go command reported its test execution as having passed, not failed. Consider this line in the JSON output:

{"Time":"2025-07-08T17:17:36.084011485Z","Action":"pass","Package":"golang.org/x/tools/gopls/internal/test/marker","Test":"Test/mcptools/symbol_references.txt","Elapsed":1.34}

Is it expected that the go command produces an "Action":"pass" instead of "Action":"fail"? If it could report the test as failed, this issue would be resolved. If it can't always do that, then the only way to do better is by having the build system work around it somehow. But it seems better to fix this in the go command if that's possible, since that benefits all its users and not just our build system.