cmd/go: spurious leading blank line before `ok` when a passing test writes unterminated output

[bushnell-deshaw]

Go version

go version go1.26.3 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/u/bushnell/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/u/bushnell/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2214924246=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/u/bushnell/go/pkg/mod'
GONOPROXY='*.deshaw.com'
GONOSUMDB='*.deshaw.com'
GOOS='linux'
GOPATH='/u/bushnell/go'
GOPRIVATE='*.deshaw.com'
GOPROXY='https://bushnell:yo80jomsa%23Td9qQlkrryBOiNDoGt98E%26%29s%21rxbzHGrh%40iB%24G2gf2797YGfF%29FMk8@artifactory.deshaw.com/artifactory/api/go/go'
GOROOT='/proj/lang/go/1.26.3/x86_64'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/u/bushnell/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/proj/lang/go/1.26.3/x86_64/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.26.3'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Run a passing test binary which writes output that does not end with a newline (typically a stderr diagnostic that uses %q or otherwise forgets the trailing \n), go test — in non-verbose, non-JSON mode. See this example:

// blank_test.go
package blanklinerepro

import (
    "fmt"
    "os"
    "testing"
)

func TestPass(t *testing.T) {}

func TestMain(m *testing.M) {
    code := m.Run()
    // Last write to stderr doesn't end in '\n'. %q is a common way to land here:
    // it emits a closing '"' as the final byte.
    fmt.Fprintf(os.Stderr, "teardown problem: %q", "some detail")
    os.Exit(code)
}

Tested with go version go1.26.3 linux/amd64. The relevant cmd/go code is unchanged on tip, so this almost certainly reproduces on every Go version since the linked CL landed.

We hit this in the wild when a teardown helper in our test infrastructure was calling something like this (note that despite the output, the tests were correctly passing):

fmt.Fprintf(os.Stderr, "failing output from subprocess: %v:\n%q", err, string(errout))

note format ending in %q, no trailing \n. When we used this helper in TestMain for some packages, every go test ./... run produced a stray blank line in front of those packages' ok lines, baked into the test cache. We fixed our format string locally, but the underlying cmd/go behavior was surprising and seems worth correcting upstream.

What did you see happen?

Running the test emits a blank line in front of the ok pkg T.TTTs summary line, with nothing above it. The captured output itself is correctly suppressed (the test passed), so the blank line is a separator dangling in front of empty space. The result is cached, so the blank line keeps reappearing on every cache hit.

$ go test -count=1 ./...
                       <-- blank line
ok  blanklinerepro  0.004s

$ go test -count=1 ./... | xxd | head -1
00000000: 0a 6f 6b 20 20 09 62 6c 61 6e 6b 6c 69 6e 65 72  .ok  .blankliner

<LF>ok  blanklinerepro  0.004s<LF>

What did you expect to see?

A passing, non-verbose run whose captured output is being suppressed should print:

ok  blanklinerepro  0.004s

with no leading blank line. The separator only makes sense when there is visible output above the ok line that needs to be ended with a newline.

[bushnell-deshaw]

In cmd/go/internal/test/test.go (Go 1.26.3, lines 1706-1731):

out := buf.Bytes()                       // snapshot of captured test-binary output
a.TestOutput = &buf

if err == nil {
    norun := ""
    if !testShowPass() && !testJSON {
        buf.Reset()                       // discard captured output for passing non-verbose runs
    }
    // ... noTestsToRun / noFuzzTestsToFuzz / tooManyFuzzTestsToFuzz checks against `out` ...
    if len(out) > 0 && !bytes.HasSuffix(out, []byte("\n")) {
        // Ensure that the output ends with a newline before the "ok"
        // line we're about to print (https://golang.org/issue/49317).
        cmd.Stdout.Write([]byte("\n"))   // cmd.Stdout == &buf, which was just Reset
    }
    fmt.Fprintf(cmd.Stdout, "ok  \t%s\t%s%s%s\n", a.Package.ImportPath, t, coveragePercentage(out), norun)
    r.c.saveOutput(a)
}

The separator decision at line 1726 uses out (the pre-reset bytes) but the write at line 1729 goes into cmd.Stdout == &buf, which on the suppression branch is empty. So the buffer that ends up cached and replayed is exactly "\nok \t<pkg>\t<time>\n".

#49317 (the change referenced in the comment) was about the opposite failure mode: when output is shown but doesn't end with \n, the first byte of the ok line was being concatenated onto the last test line. The fix added the separator unconditionally and did not account for the suppression branch.

Suggested fix

Make the separator conditional on the buffer actually being non-empty after the suppression decision — i.e. gate on buf.Len() > 0 instead of len(out) > 0:

if buf.Len() > 0 && !bytes.HasSuffix(out, []byte("\n")) {
    cmd.Stdout.Write([]byte("\n"))
}

That preserves the #49317 fix in all the cases where the trailing test output is actually visible (verbose mode, failing tests, the streaming branches at line 1491 / 1496 where stdout was never &buf to begin with — in those bran
ches buf.Len() after the Reset is still equal to whatever was streamed, but the suffix check on the snapshot still reflects what the user saw), while skipping the separator on the one branch where the output has been thrown away.

(An alternative that is arguably cleaner: skip the entire conditional when !testShowPass() && !testJSON, since in that mode no captured output is being printed before the ok line and there is therefore nothing to separate from.)

[gabyhelp]

Related Issues

• cmd/test2json: test output without trailing newline missing final status #57172 (closed)
• testing: stdout output with no newline produces confusing/corrupt -v output #26325 (closed)
• testing: bad output formatting when test stdout ends in an incomplete line #38063 (closed)
• cmd/go: FAIL line printed by "go test" corrupted when test output does not end in a newline #49317 (closed)
• testing: fmt.Print missing a trailing newline interferes with test output formatting #35845 (closed)
• cmd/go: test2json does not recognize test status if output did not end with new line #47032 (closed)
• stdout messes up `go test --json` #36576 (closed)

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

[dmitshur]

Thanks for the report. Would you like to send a CL? https://go.dev/doc/contribute

[gopherbot]

Change https://go.dev/cl/799182 mentions this issue: cmd/go: avoid a blank line before ok when discarded output lacks a newline

[prattmic]

cc @golang/command-line

Is this a pre-existing issue, or a regression in 1.26?