## TL;DR

The race detector found unsynchronized shared memory access. Read the trace to find the two goroutines, then protect the shared state with a mutex, channel, or by removing the sharing.

## Error

```text
WARNING: DATA RACE
Read at 0x00c0000 by goroutine 8:
  main.process()
Previous write at 0x00c0000 by goroutine 7:
  main.update()
```

## Steps

1. Run with `-race -run TestName -count=1` to reproduce. Expected: the trace names both goroutines and the variable.
2. Identify the shared variable and the two access sites. Expected: you know what is shared.
3. Fix: mutex around the critical section, channel for handoff, or `sync.Map` for concurrent maps. Expected: one clear synchronization choice.
4. Re-run with `-race`. Expected: no warning.
5. Run the full package with `-race`. Expected: no other races hiding nearby.

## When to use

- `WARNING: DATA RACE` in test output.
- Concurrent tests or code under test.

## When not to use

- Test logic failures without the race warning.
- You need `-race` in CI (separate decision; do it).

## Tool compatibility

- Go 1.20+; `-race` detector.

## Variant phrasings

### Go test race condition

The general term; the detector makes it precise.

### data race in Go test

Same thing; read the trace.

## Why it happens

Goroutines share memory by default. Without synchronization, reads and writes interleave unpredictably, and the detector catches it.

## Edge cases

- The race may be in test code (shared test fixtures), not production code.
- `-race` slows tests 5-10x; run it in CI, not necessarily on every local run.
- Maps are the most common race site; `sync.Map` or mutexes fix them.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FCSWJ-ySWnSqlVzhNyf5Tg