Sidebar shows stray "Playouts 3" badge (and "1 failing" health chip) on a fresh empty DB #218

Closed
opened 2026-07-10 07:56:35 +02:00 by timothy · 3 comments
Owner

Seen twice during #216 live E2E (fresh scratch config, zero playouts): the sidebar Playouts nav entry renders a "3" badge and the footer shows "1 failing" on a brand-new database. Likely the badge/health source is miscounting (default channel? health checks?) or reading a wrong field. Repro: scripts/e2e-local.sh with a fresh config dir, open /app. Not investigated; filed from the 2026-07-10 session.

Seen twice during #216 live E2E (fresh scratch config, zero playouts): the sidebar Playouts nav entry renders a "3" badge and the footer shows "1 failing" on a brand-new database. Likely the badge/health source is miscounting (default channel? health checks?) or reading a wrong field. Repro: scripts/e2e-local.sh with a fresh config dir, open /app. Not investigated; filed from the 2026-07-10 session.
timothy added the bugfrontendpriority: mediumreview labels 2026-07-10 08:28:02 +02:00
Author
Owner

Retro review (adversarial-reviewer#18): the two symptoms are unrelated and should not share one uninvestigated root-cause bucket.

  • The Playouts 3 is confirmed static prototype residue: the route literal in web/src/App.tsx has badge: 3, and SidebarNavGroup renders it directly. It is unrelated to the database and needs removal or replacement with a live count plus a zero-state test.
  • The 1 failing footer is derived independently from GET /api/health by summarizeHealth. On a scratch E2E environment it may be a legitimate FFmpeg/environment health failure; “fresh DB” alone does not prove it is wrong.

Narrow #218 to the confirmed hard-coded badge. Record the actual failing health check title/status/detail from the repro before deciding whether there is a second bug; file that separately if the check is invalid. Added review/medium-priority labels.

Retro review (adversarial-reviewer#18): the two symptoms are unrelated and should not share one uninvestigated root-cause bucket. - The Playouts `3` is confirmed static prototype residue: the route literal in `web/src/App.tsx` has `badge: 3`, and `SidebarNavGroup` renders it directly. It is unrelated to the database and needs removal or replacement with a live count plus a zero-state test. - The `1 failing` footer is derived independently from `GET /api/health` by `summarizeHealth`. On a scratch E2E environment it may be a legitimate FFmpeg/environment health failure; “fresh DB” alone does not prove it is wrong. Narrow #218 to the confirmed hard-coded badge. Record the actual failing health check title/status/detail from the repro before deciding whether there is a second bug; file that separately if the check is invalid. Added `review`/medium-priority labels.
timothy added the in-progress label 2026-07-11 01:41:21 +02:00
Author
Owner

claiming — session started 2026-07-10 ~23:00 (retroactive label per the #237 protocol adopted mid-session). Fix is in flight: PRs #222–#228 cover #221/#220/#217+#219/#215/#218/#213; awaiting CI green → merge → close.

claiming — session started 2026-07-10 ~23:00 (retroactive label per the #237 protocol adopted mid-session). Fix is in flight: PRs #222–#228 cover #221/#220/#217+#219/#215/#218/#213; awaiting CI green → merge → close.
Author
Owner

Closed via PR #226 (integration PR #239)

Root cause — both halves identified:

  1. The "Playouts 3" badge was a hard-coded badge: 3 in the nav route definition (App.tsx:365) — design-mock scaffolding never wired to data; Blazor had no equivalent badge. Removed (badge mechanism kept for future live use; verified no other hard-coded nav badges exist).
  2. The "1 failing" footer chip is not a bug: it renders live GET /api/health. Evidence captured on a fresh scratch instance during the #220 E2E run: the failing check is genuinely FFmpeg Capabilities — local Homebrew ffmpeg 8.1.2 lacks the subtitles/zscale filters (prod's ffmpeg image has them). Environment-specific, correct behavior; the content/DB checks all pass on an empty database. No code change.

Verification: tsc + full web suite green; no test referenced the badge value.

## Closed via PR #226 (integration PR #239) **Root cause — both halves identified**: 1. The "Playouts 3" badge was a hard-coded `badge: 3` in the nav route definition (`App.tsx:365`) — design-mock scaffolding never wired to data; Blazor had no equivalent badge. Removed (badge mechanism kept for future live use; verified no other hard-coded nav badges exist). 2. The "1 failing" footer chip is **not a bug**: it renders live `GET /api/health`. Evidence captured on a fresh scratch instance during the #220 E2E run: the failing check is genuinely `FFmpeg Capabilities` — local Homebrew ffmpeg 8.1.2 lacks the `subtitles`/`zscale` filters (prod's ffmpeg image has them). Environment-specific, correct behavior; the content/DB checks all pass on an empty database. No code change. **Verification**: tsc + full web suite green; no test referenced the badge value.
timothy removed the in-progress label 2026-07-11 11:37:04 +02:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: timothy/ersatztv#218