Dashboard can't preview weather for a city you haven't saved

Nobody has started this yet — be first.

Business impact

A user deciding whether to save a new city (e.g. searching "should I add Berlin to my dashboard?") has to actually save it first just to see its current weather -- there's no "preview before you commit" flow. This is friction on exactly the action (adding a city) the product most wants to be frictionless.

Problem

GET /dashboard always resolves weather for the caller's saved city list only. The diagnostic benchmark endpoint (GET /diagnostics/benchmark) already supports an ad-hoc ?cities=a,b,c override that bypasses the saved list entirely -- but the main dashboard endpoint has no equivalent.

Current behavior

GET /dashboard?cities=Berlin,Madrid ignores the query parameter entirely and returns weather for the caller's saved cities only, with no way to preview an unsaved city.

Expected behavior

GET /dashboard?cities=Berlin,Madrid fetches weather for exactly the given (comma-separated) cities instead of the caller's saved list -- using the same cache/fetch/parallel machinery as today, just with a different city-name source. Omitting ?cities= keeps today's "use my saved list" behavior exactly as-is.

Steps to reproduce

curl -X POST http://localhost:8083/cities -H 'X-User-ID: alice' -d '{"name": "Osaka"}' curl "http://localhost:8083/dashboard?cities=Berlin,Madrid" -H 'X-User-ID: alice'

-> results for Osaka only (the saved list), ignoring the ?cities= param entirely

Why this matters

The parsing/splitting logic for this exact query-param shape already exists, working correctly, in handleBenchmark a few lines below in the same file -- this ticket is about reusing that pattern for the main dashboard path rather than inventing a new one, and resisting the temptation to just copy-paste it awkwardly instead of factoring out the shared bit.

Suggested approach

Look at how handleBenchmark parses ?cities= into a []string of city names, and apply the same approach in handleDashboard, falling back to s.cities.List(...) (today's only behavior) when ?cities= is absent.

Acceptance criteria

GET /dashboard?cities=Berlin,Madrid returns results for exactly those two cities, regardless of what's in the caller's saved list.
GET /dashboard (no query param) is completely unaffected -- same behavior as before this ticket.
Ad-hoc cities go through the same cache/parallel-fetch path as saved cities (a repeated ad-hoc request for the same city within the cache TTL doesn't re-hit upstream).
An empty ?cities= (present but blank) falls back to the saved-city list rather than returning an empty/error response.
practicetickets/ticket06_dashboard_ad_hoc_cities_test.go passes.

Verification

WD_TEST_DATABASE_URL=postgresql://... go test ./practicetickets/... -run TestTicket06 -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 feat/dashboard-ad-hoc-cities

Fix it and commit

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

Push the branch

$git push -u origin feat/dashboard-ad-hoc-cities

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).