Dashboard fetch has a data race on the shared results slice

Nobody has started this yet — be first.

Business impact

Under real concurrent load -- multiple cities fetched in parallel, which is this feature's entire reason to exist -- the dashboard endpoint can return corrupted results: city entries missing, duplicated, or a response whose result count doesn't match the number of saved cities, because multiple goroutines are mutating the same slice concurrently without synchronization. This is the class of bug that passes every manual test (works fine on a laptop, most of the time) and then intermittently corrupts production responses under real traffic -- exactly why this project's own README calls out "confirm no data races on the shared results collection" as a hard requirement, not a nice-to-have.

Problem

FetchAll now builds results by having every goroutine call results = append(results, f.fetchOne(gctx, city)) against one shared, unsynchronized []CityResult variable, instead of each goroutine writing to its own pre-assigned index of a slice sized up front.

Current behavior

go test -race reports a genuine DATA RACE on the shared results slice; without -race, the same unsynchronized append can silently lose an update, producing a dashboard response with fewer results than saved cities.

Expected behavior

Each goroutine writes only to its own index of a slice sized up front (results := make([]CityResult, len(cityNames)); results[i] = ...), which is race-free without needing a mutex because no two goroutines ever touch the same memory location.

Steps to reproduce

go test -race ./internal/dashboard/... -run TestFetchAll_ConcurrentPartialFailure -v

The Go race detector reports a DATA RACE on concurrent access to the results slice --

a real, tool-confirmed race: every goroutine's append reads-then-writes the shared slice

header's length/pointer/capacity fields with no happens-before relationship between

goroutines.

Why this matters

append on a slice shared across goroutines is unsafe even when it "usually looks fine" in casual testing, because append reads the slice header (len/cap/pointer), decides whether to reallocate, and writes back a new header -- none of that is atomic, so two goroutines racing through it can both read the same starting state and each overwrite the other's update, silently dropping a result, independent of whether the race detector happens to be running to catch it.

Suggested approach

Compare the current FetchAll against its own doc comment two lines above the function (still describing the pre-sized, indexed-write approach) and against Benchmark's sequential loop just below in the same file, which never had this problem because it doesn't run concurrently. The fix is a return to indexed writes into a pre-sized slice, keeping the same errgroup/SetLimit concurrency bound unchanged.

Acceptance criteria

go test -race ./internal/dashboard/... passes clean -- no race reported.
TestFetchAll_ConcurrentPartialFailure's existing assertions (every city present, failing city flagged, others fresh, roughly-parallel timing) all pass.
Result order still matches input city order.
practicetickets/ticket10_race_test.go passes under -race.

Verification

go test -race ./practicetickets/... -run TestTicket10 -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/dashboard-results-race

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/dashboard-results-race

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Weather Dashboard — Resilient Fetching Against a Flaky Upstream

A Go weather-dashboard API demonstrated by fanning out live weather fetches for a user's saved cities in parallel -- bounded retry-with-backoff against a genuinely flaky upstream, a TTL cache with stale-data fallback, and safe, mutex-free concurrent writes are the central engineering problems, not an afterthought.

Fork on GitHub

Download

Setup

Weather Dashboard — Resilient Fetching Against a Flaky Upstream

git clone <your-fork>
cd weather_dashboard
cp .env.example .env   # adjust as needed
docker compose up --build   # postgres (5435) + app (8083) + mockweather (internal-only)

The compose project is named so its commands don't collide with sibling projects on the same machine. Three services start: (Postgres, host port 5435), (host port 8083), and (the local fake weather provider -- not published to the host, only reachable from inside the compose network). No real OpenWeatherMap API key is needed for any local dev, test, or compose run; to point the app at the real provider instead, set and a real -- no code changes required (see for the prod-shaped overrides that drop the mock provider entirely).