Why is calling t.Fatalf from a goroutine your Go test spawned unsafe?

## What Fatalf actually does `t.Fatalf(format, args...)` is two steps: it logs the message and marks the test as failed (the `Errorf` half), then it calls `FailNow`. And `FailNow` is not a `return` and not a `panic` — it calls `runtime.Goexit()`. `runtime.Goexit` terminates the calling goroutine. It runs that goroutine's deferred functions and then the goroutine is gone; no other goroutine is affected, and the program does not exit. That is precisely how the testing package stops a test at the point of a fatal error: the test function *is* a goroutine, so ending it ends the test, and the testing package's own machinery notices and moves on. ## Why that breaks from a spawned goroutine The documented contract is that `FailNow`, and therefore `Fatal`/`Fatalf`/`SkipNow`, must be called from the goroutine running the test or benchmark function, not from other goroutines created during the test. Break it and three things can happen, in rough order of nastiness: 1. **The test does not stop.** The failure flag is set, but the test function is a different goroutine and keeps executing. It carries on with the state that the worker just declared invalid — typically producing a cascade of further failures, or a nil dereference whose stack points nowhere near the real problem. 2. **The fatal call is lost in a race with the test's own completion.** If the test function returns before the worker gets to its `t.Fatalf`, the call happens after the test has finished, and the testing package panics with `Log in goroutine after TestX has completed`. That panic takes down the whole test binary, and the message is about the *logging*, not about the actual bug. 3. **The worker silently disappears.** `Goexit` kills that goroutine on the spot. Anything the worker still had to do — closing a channel other goroutines are waiting on, releasing a resource, signalling completion — never happens, so a test that would have failed cleanly now hangs somewhere else. ## What is safe from another goroutine `testing.T`'s reporting methods split into two groups: - **Safe for concurrent use from any goroutine:** `Log`, `Logf`, `Error`, `Errorf`, `Fail`, `Failed`, `Name`. `Error` is `Log` plus `Fail`; it marks the test failed and *returns*, which is exactly what you want from a worker. - **Test-goroutine only:** `FailNow`, `Fatal`, `Fatalf`, `SkipNow`, `Skip`, `Skipf`, and `t.Parallel`. So the minimum fix is mechanical: in a spawned goroutine, replace `t.Fatalf(...)` with `t.Errorf(...)` followed by an explicit `return`. The `return` matters — without it you lose the fail-fast behaviour you were relying on and the goroutine proceeds into the state it just complained about. ## The better shape: report at the join point Better still, do not report from the worker at all. Hand the error back to the test goroutine, which is the one allowed to stop the test: ```go errCh := make(chan error, 1) go func() { errCh <- svc.Warm(ctx) }() if err := <-errCh; err != nil { t.Fatal(err) } ``` The channel is buffered so the worker can finish even if the test abandons the wait; the `t.Fatal` runs on the test goroutine, where it means what it says. This also concentrates the assertions in one readable place instead of scattering them across closures. ## The trap that bites in real suites The rule is easy to obey in a plain `go func(){}` and easy to forget everywhere else, because any callback the test provides may be invoked on somebody else's goroutine. The classic case is a test HTTP handler: `httptest.NewServer` serves each request on its own goroutine, so a `t.Fatalf` inside the handler is exactly this bug wearing a disguise. The same applies to a callback passed into the code under test, an `http.Client` transport hook, or a subscriber function invoked by a background loop. If the function might be called by code you did not `go` yourself, treat it as another goroutine. ## Tooling `go vet` ships a `testinggoroutine` analyzer that reports calls to `Fatal`, `FailNow` and friends from goroutines started by a test — it catches the obvious direct cases. It cannot see through an interface or a callback you registered, so the review habit still matters: any `testing.T` inside a closure deserves a second look at which goroutine will run it. ## The one-line rule Fail fast only from the goroutine that owns the test; from everywhere else, record with `Errorf` and return, or send the error home.