MonthPage and RecordsPage each made two backend calls sequentially
(CityMonth/CityRecords, then City) where the second never depended on the
first's result -- both are independent single-slug lookups. Waiting for
one full round trip before even starting the other was pure latency with
nothing to show for it.
fetchWithCity launches both concurrently via goroutines and a WaitGroup.
Verified live against a stub with an injected 400ms delay on both
endpoints: city page (1 call) and month/records pages (2 calls each) all
cost ~0.404s now, not ~0.404s vs ~0.8s -- the two-call pages no longer pay
double.
Error priority is preserved exactly: if the primary call fails, its error
wins even when City also fails or hasn't finished, matching the old
sequential code (which never called City() once primary had already
failed). The one real trade-off, called out in the comment: City() is now
always launched even on a request that's about to 404 from primary, so an
invalid slug costs one extra (wasted, cheap) backend lookup it previously
skipped -- worth it since a bad slug is the rare path and a good one is
the common path this speeds up.
Tests: happy path; primary-error-wins and city-error-surfaces (both single
and combined failure); and a deterministic concurrency proof via
rendezvous channels rather than timing (the old sequential code would
deadlock this test, not just run it slower). Full suite green under
`-race -count=2`. Docker build (which runs `go test` inside the image)
passes.
Found while checking live status: beta's thermograph-daemon container was
still running an old backend image tag while backend/lake had rolled
forward twice. Reproduced directly against the host rather than guessing --
`docker compose config --images daemon` does NOT filter to the named
service on this host's Compose v5.3.1: it prints every service's image,
one per line, in file order, so `| head -1` was silently grabbing db's
image (timescaledb) instead of daemon's. The probe then always found no
/usr/local/bin/thermograph-daemon in a Postgres image and concluded "this
image predates the daemon binary," dropping daemon from every single
backend deploy regardless of what the real backend image actually
contained -- the exact /internal/* version-skew this guard was written to
prevent, caused by the guard itself.
Fixed by building the image reference directly from the same vars
docker-compose.yml's daemon.image: already interpolates
(REGISTRY_HOST/BACKEND_IMAGE_PATH/BACKEND_IMAGE_TAG) instead of going
through `docker compose config` at all -- no dependency on that command's
filtering behavior, and it can't disagree with what compose will actually
run.
Verified directly against beta: the old code's exact command sequence
reproduced with real secrets sourced, confirmed the wrong (db) image was
selected; the new construction resolves to the correct backend image and
the binary probe passes.
