mhoennigandClaude Opus 5
18a41e9ced
A wrong git token made the watcher fail every fetch for 57 minutes while the branches view kept showing its last known list. WatcherState already records lastFetchError and /api/watcher already serves it; only the UI never renders it. The step also folds in the logging volume: one outage wrote 297 identical warnings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
53 lines
3.4 KiB
Markdown
53 lines
3.4 KiB
Markdown
# Step 19: Show a stalled watcher in the web UI
|
|
|
|
Prerequisites: none — the data already exists, only nothing renders it.
|
|
Read `README.md` first.
|
|
|
|
## Why
|
|
|
|
On 2026-08-30 the Gitea token in the machine config on vm4006 was replaced by a placeholder string.
|
|
For 57 minutes GitTally failed `git fetch --prune origin` every ten seconds and wrote 297 warnings to the journal.
|
|
The branches view showed a calm, ordinary list the whole time: every branch with its last build, nothing amiss.
|
|
The failure was noticed only because an expected build did not start, and it took reading the journal to see why.
|
|
|
|
A watcher that cannot reach origin means every branch row on the page is stale — the one thing the page exists to tell.
|
|
Silence is the wrong answer, and the journal is not the user interface.
|
|
|
|
## What Already Works
|
|
|
|
`Watcher.poll` records the failure: `state = state.copy(lastPollAt = …, lastFetchError = e.message ?: …)`, cleared again after a clean cycle.
|
|
`WatcherApiController` serves it at `/api/watcher` as `WatcherState`, which distinguishes three failure modes:
|
|
|
|
- `lastFetchError` — origin unreachable (credentials, network, gone remote);
|
|
- `lastPollError` — the cycle crashed after a successful fetch;
|
|
- `running: false` — the poll loop is not scheduled at all.
|
|
|
|
All three mean the same thing to a reader: what you see is not current.
|
|
The endpoint needs no change.
|
|
|
|
## Code
|
|
|
|
- `static/gittally.js`: fetch `/api/watcher` from the same polling cycle that refreshes the view, and show a banner while any of the three conditions holds.
|
|
Keep the existing discipline — a timeout on the fetch, and a failure of *this* request must never break the view's own refresh.
|
|
- `templates/fragments.html`: add a `watcher-banner` fragment to the `nav(view)` row so every view inherits it; hidden unless the script fills it.
|
|
- Wording says what is stale and since when, not just that something failed: the branch list is not updating, since `lastPollAt`, because `<error>`.
|
|
Timestamps go through the shared formatting — `UiFormats` and `gittally.js` must produce identical formats (invariant in `AGENTS.md`).
|
|
- Do not overload `live-indicator`: it reports whether the *browser* reaches the server.
|
|
This banner reports whether the *server* reaches origin. Two independent failures, two independent signals.
|
|
|
|
While in there, fix the logging volume: one outage produced 297 identical warnings.
|
|
Log the fetch failure when its message changes, not on every cycle, and log once more when the fetch succeeds again.
|
|
This is the same class as the `atTimes` warning that repeats every poll for an invalid slot — fix both or neither, but do not leave the new one behind.
|
|
|
|
## Tests
|
|
|
|
- `server/WatcherApiControllerTest.kt` — assert that a state carrying `lastFetchError` reaches the JSON, so the field the UI depends on is covered.
|
|
- `watcher/WatcherTest.kt` — a failing `fetchOrigin` sets `lastFetchError` and a following clean cycle clears it; a repeated identical failure logs once.
|
|
- The JavaScript has no test harness; the banner is verified manually below.
|
|
|
|
## Verification
|
|
|
|
- Break it deliberately in a scratch repo install: set `git.token` to a wrong value, and watch the banner appear within one poll interval and disappear again after fixing it.
|
|
- Stop the watcher (`running: false`) and confirm the banner says so in its own words rather than reporting a fetch error.
|
|
- On a narrow viewport the banner must not push the table off screen.
|