I think this change would reduce the probability of a race, but not completely eliminate it.

In the current version of the code, the goroutine that generates the log message is reading coderd.options.Logger, then calling Debug() on it which eventually calls t.Log(). Making Logger an atomic reference and clearing it during cleanup doesn't fix this, because a concurrently running goroutine might read the value of Logger before it's cleared, but then call t.Log() after the test exits.

Here's a minimal example that demonstrates the same issue. It succeeds on the playground, but fails if run with -race -count=100.

I think fixing this properly requires pushing the synchronization all the way to slogtest.testSink. Something like:

type testSink struct {
    tb testing.TB
    mutex sync.Mutex
    testDone bool
}

I looked into doing something like that as my first option, but how would the test sink know when the test exits?

Hmm, I guess maybe if the sink had its own t.Cleanup that set the flag that would work?

Yeah, at first I was thinking we'd have to make slogtest.Make return an extra function/object/something to provide a way for the test code to signal that it was done, but just having the sink register its own cleanup function is much more elegant.

Closing in favor of coder/slog#146 and #1759