The app reports cache freshness but never its own code version #12

New issue

Closed

opened 2026-08-27 20:57:39 +02:00 by solvreven · 0 comments

solvreven commented

2026-08-27 20:57:39 +02:00

Owner

This cost a live debugging session on 2026-08-27.

A fix to /api/matches was verified against the cache file and against stubbed
deps, and the tab still showed the old gameweek. Cause: the server process had
been running since 23 August. It had hot-reloaded the rebuilt cache
(built_at 2026-08-27T18:07) while running four-day-old code.

That state is invisible from the UI. /api/status reports built_at and drives
a staleness banner for the cache; nothing reports the server's own version.
So a process running stale logic against fresh data looks completely healthy —
green banner, numbers moving on every rebuild — and the only symptom is that a
fix you know landed does not appear.

The cache already carries built_from_sha. The running process should report
its own git SHA and start time beside it, so the two can be seen to
disagree. CLAUDE.md's rule — "stamp artefacts with their build time and git
SHA, and print both in every report" — applied to the one artefact nobody
stamped: the server itself.

Suggested fix. Add server_sha and server_started_at to /api/status,
and surface a warning when server_sha != cache.built_from_sha.

**This cost a live debugging session on 2026-08-27.** A fix to `/api/matches` was verified against the cache file and against stubbed deps, and the tab still showed the old gameweek. Cause: the server process had been running since 23 August. It had **hot-reloaded the rebuilt cache** (`built_at 2026-08-27T18:07`) while running four-day-old code. That state is invisible from the UI. `/api/status` reports `built_at` and drives a staleness banner for the *cache*; nothing reports the *server's* own version. So a process running stale logic against fresh data looks completely healthy — green banner, numbers moving on every rebuild — and the only symptom is that a fix you know landed does not appear. The cache already carries `built_from_sha`. The running process should report its own git SHA and start time beside it, so the two can be **seen to disagree**. CLAUDE.md's rule — "stamp artefacts with their build time and git SHA, and print both in every report" — applied to the one artefact nobody stamped: the server itself. **Suggested fix.** Add `server_sha` and `server_started_at` to `/api/status`, and surface a warning when `server_sha != cache.built_from_sha`.

solvreven referenced this issue

2026-08-29 16:15:14 +02:00

fixtures_raw is frozen at server startup while refresh-live refreshes only the bootstrap #17

solvreven referenced this issue

2026-08-29 20:49:34 +02:00

Track purchase prices so FPL selling prices can be computed #18