Any upstream failure crashes the request instead of falling back

Nobody has started this yet — be first.

Business impact

The entire reason this project's cache/stale-fallback design exists is so a real-world upstream hiccup degrades gracefully (stale data with a warning, or a clear per-city error) instead of taking down the whole request. Right now, any upstream failure for any city -- a timeout, a 404, a 5xx, rate-limiting, anything -- instead causes a nil-pointer panic while handling that city's result. The panic-recovery middleware catches it and turns it into a generic 500, so the process doesn't crash outright -- but every single upstream failure, for any reason, now surfaces as an opaque server error to the client instead of the carefully-designed stale/error response this project's own README describes as its core resilience feature. Under any real, non-trivial outage window, this makes the dashboard endpoint essentially unusable exactly when its fallback behavior matters most.

Problem

fetchOne is supposed to cache the fetched data only when the upstream call actually succeeded -- but the call that stores the result into the cache now runs unconditionally, before checking whether the fetch actually returned an error. On the failure path, the fetched data pointer is nil, and dereferencing it to store into the cache panics.

Current behavior

Any per-city upstream failure -- a timeout, a 404, a 5xx, rate-limiting -- panics with a nil-pointer dereference inside fetchOne instead of returning the intended stale/error CityResult; GET /dashboard surfaces it as a bare 500 via the panic-recovery middleware.

Expected behavior

The cache is only updated on a successful fetch; on failure, fetchOne proceeds directly to its existing stale-fallback / per-city-error logic (both of which are still correct and untouched), without ever touching the cache.

Steps to reproduce

Configure a fetch for a city with no prior cache entry, using a fake provider that returns an error. fetcher.FetchAll(ctx, []string{"Atlantis"})

Expected: a CityResult with Status: "error" and a populated Error field.

Actual: a nil-pointer-dereference panic inside fetchOne, recovered as a 500 if reached

via GET /dashboard.

Why this matters

This is exactly the "no panics anywhere, including on... an unexpected nil" production-scale bar this project's own README calls out explicitly -- a cache-write that got moved earlier in the function (perhaps during a refactor) without also moving its success-only guard is a realistic, easy mistake: nothing about a cache write "looks" conditional at a glance, so it's easy to reorder code around it without noticing the guard needs to move too.

Suggested approach

Look at where f.cache.Set(...) is called in fetchOne relative to where the fetch's returned error is actually checked -- compare it against the two branches immediately below (stale fallback, per-city error), which correctly only run on the failure path.

Acceptance criteria

A successful fetch still updates the cache (unaffected).
A failed fetch with no prior cache entry returns a clean per-city StatusError result -- no panic.
A failed fetch with a prior (now-stale) cache entry returns the existing stale-fallback behavior -- no panic, and the cache is not corrupted with the failed attempt's (nonexistent) data.
TestFetchAll_ConcurrentPartialFailure's existing assertions all still pass once this is fixed correctly.
practicetickets/ticket09_cache_set_panic_test.go passes.

Verification

go test ./practicetickets/... -run TestTicket09 -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 fix/cache-set-panic

Fix it and commit

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

Push the branch

$git push -u origin fix/cache-set-panic

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