Dashboard doesn't say how old cached/stale data actually is

Nobody has started this yet — be first.

Business impact

When a city's entry is stale, the dashboard response currently just says "status": "stale" with a human-readable warning string embedded in prose -- a client can't tell programmatically whether that data is 2 minutes old (barely stale, basically fine) or 2 days old (seriously outdated, maybe worth hiding). Every consumer of this API is stuck parsing English out of the warning field if they want to show "as of 12 minutes ago" instead of a bare "stale" badge.

Problem

weather.CurrentWeather already carries a FetchedAt timestamp (correctly populated and already serialized as fetched_at in JSON) -- a client can compute staleness itself by diffing fetched_at against the current time. But dashboard.CityResult has no server-computed "how old is this" convenience field, so every client has to redo that same diff-against-now arithmetic itself instead of just reading a number.

Current behavior

A CityResult carrying weather data has no age_seconds field at all; clients wanting to show "as of N minutes ago" have to re-derive it themselves from fetched_at.

Expected behavior

Every CityResult that carries weather data (fresh or stale) also includes a server-computed age_seconds integer field -- how many seconds old the data was at the moment the response was built -- so a client can show "as of 12 minutes ago" (or decide to hide data past some threshold) by reading one field, not by parsing a human-readable warning string or re-deriving the diff itself.

Steps to reproduce

curl http://localhost:8083/dashboard -H 'X-User-ID: alice'

every result carrying weather data has no age_seconds field at all -- clients must diff

fetched_at against the current time themselves

Why this matters

The raw ingredient (FetchedAt) already flows correctly through both the fresh and stale-fallback paths -- this ticket is about deriving and exposing one new field from it (time.Now().Sub(FetchedAt), in seconds) at the point a CityResult is built, not about fixing broken timestamp plumbing.

Suggested approach

Add an AgeSeconds int64 field (tagged json:"age_seconds") to dashboard.CityResult, and compute it (from the now-current time minus the relevant Weather.FetchedAt) everywhere a CityResult carrying Weather is constructed in fetchOne (both the fresh-fetch branch and the stale-fallback branch).

Acceptance criteria

A fresh CityResult's age_seconds is a small non-negative number (it was just fetched).
age_seconds is present whenever Weather is non-nil, and absent (or omitted) when it's nil (the plain error case).
Existing behavior (status, weather, warning, error fields) is completely unaffected -- this is purely an addition.
practicetickets/ticket07_cache_age_metadata_test.go passes.

Verification

go test ./practicetickets/... -run TestTicket07 -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/cache-age-metadata

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/cache-age-metadata

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