Files
ontime/apps/server
Claude 8551c161f1 fix(report): correct run timestamps, scoping and recovery
Review of the run history feature turned up four defects, all in the
code that feature introduced.

- Runs were dated with a time of day rather than a wall clock instant.
  `clock` and `rundown.actualStart` are millis since midnight, so every
  run in the history list rendered as 1 January 1970, and getLatestRun
  ordered runs incorrectly across days: a run at 09:00 today sorted below
  one at 20:00 last week, so the "last run" chip and /runs/latest could
  return an older run. Runs now take `_startEpoch`, the instant the show
  began, and the type documents the invariant.
- A stop arriving with no run open is ignored. Loading a project stops
  playback and reinitialises reporting in the same tick, and the trailing
  stop was attributing the previous project's event to the new one.
- Run summaries counted planned events from the loaded rundown rather
  than the rundown the run belongs to, so switching rundowns mid-run gave
  the summary a denominator from a different rundown. A run whose rundown
  has since been deleted now keeps its last known count instead of
  dropping to zero.
- Recovery of runs left open by a crash only closed the first one. Any
  others stayed dangling forever: permanently shown as ongoing and never
  eligible as the latest run.

Also replaces the raw ISO default run label with a readable local date
and time, and adds a batching upsertRuns to the store so recovery writes
the sidecar once rather than racing one write per run.

Each fix has a regression test, verified to fail without the change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019nr3FbLbM8gB8Jm771YgTV
2026-08-08 16:21:00 +00:00
..
2026-03-08 16:22:12 +01:00
2026-03-08 16:22:12 +01:00
2026-03-08 16:22:12 +01:00
2026-07-18 15:24:25 +02:00
2026-03-08 16:22:12 +01:00
2026-03-08 16:22:12 +01:00
2026-03-08 16:22:12 +01:00