Jinemi/thermograph

Fork 0

frontend: fetch City() concurrently with the page's primary API call #37

Merged

admin_emi merged 3 commits from frontend-concurrent-fetch into main

2026-07-24 06:25:09 +00:00

admin_emi commented

2026-07-24 06:04:41 +00:00

Owner

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, not just structurally

Built the binary, ran it against a stub content API with an injected
400ms delay on both endpoints, and timed cold requests on fresh server
instances (bypassing the response cache):

Route	Backend calls	Cold latency
City page	1	0.404s
Month page	2, concurrent	0.404s (was would-be ~0.8s sequential)
Records page	2, concurrent	0.404s

The two-call pages now cost the same as a single call, not the sum of two.

Error priority 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() at all once primary had already failed).

One real trade-off, called out in the code 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 — a bad slug is the rare path, 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 cases.
A deterministic concurrency proof via rendezvous channels rather than
timing: the old sequential code would deadlock this test (and fail its
timeout), not just run it slower — a stronger guarantee than a flaky
wall-clock assertion.
Full suite green under -race -count=2.
Docker build (which runs go test inside the image) passes.

`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, not just structurally Built the binary, ran it against a stub content API with an **injected 400ms delay** on both endpoints, and timed cold requests on fresh server instances (bypassing the response cache): | Route | Backend calls | Cold latency | |---|---|---| | City page | 1 | 0.404s | | Month page | 2, concurrent | **0.404s** (was would-be ~0.8s sequential) | | Records page | 2, concurrent | **0.404s** | The two-call pages now cost the same as a single call, not the sum of two. ## Error priority 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()` at all once primary had already failed). **One real trade-off**, called out in the code 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 — a bad slug is the rare path, 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 cases. - A **deterministic** concurrency proof via rendezvous channels rather than timing: the old sequential code would *deadlock* this test (and fail its timeout), not just run it slower — a stronger guarantee than a flaky wall-clock assertion. - Full suite green under `-race -count=2`. - Docker build (which runs `go test` inside the image) passes.

admin_emi added 2 commits 2026-07-24 06:04:42 +00:00

deploy.sh: fix the daemon-binary probe, which always dropped daemon

PR build (required check) / changes (pull_request) Successful in 6s

Details

secrets-guard / encrypted (pull_request) Successful in 6s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

PR build (required check) / build-frontend (pull_request) Has been skipped

Details

shell-lint / shellcheck (pull_request) Successful in 8s

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details

PR build (required check) / gate (pull_request) Successful in 2s

Details

cf0fa01892

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.

frontend: fetch City() concurrently with the page's primary API call

shell-lint / shellcheck (pull_request) Failing after 10m43s

Details

secrets-guard / encrypted (pull_request) Failing after 10m45s

Details

PR build (required check) / changes (pull_request) Failing after 10m47s

Details

PR build (required check) / build-backend (pull_request) Has been cancelled

Details

PR build (required check) / build-frontend (pull_request) Has been cancelled

Details

PR build (required check) / validate-observability (pull_request) Has been cancelled

Details

PR build (required check) / gate (pull_request) Has been cancelled

Details

2f0bda1e28

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.

admin_emi added 1 commit 2026-07-24 06:23:44 +00:00

re-trigger CI: prior run was orphaned by a mid-run runner reboot (unrelated to this change)

secrets-guard / encrypted (pull_request) Successful in 5s

Details

PR build (required check) / changes (pull_request) Successful in 7s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

shell-lint / shellcheck (pull_request) Successful in 7s

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details