2f0bda1e28
Some checks failed
shell-lint / shellcheck (pull_request) Failing after 10m43s
secrets-guard / encrypted (pull_request) Failing after 10m45s
PR build (required check) / changes (pull_request) Failing after 10m47s
PR build (required check) / build-backend (pull_request) Has been cancelled
PR build (required check) / build-frontend (pull_request) Has been cancelled
PR build (required check) / validate-observability (pull_request) Has been cancelled
PR build (required check) / gate (pull_request) Has been cancelled
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. |
||
|---|---|---|
| .. | ||
| config | ||
| content | ||
| contentapi | ||
| contentdata | ||
| format | ||
| handlers | ||
| render | ||