Counters at the top are not updating until page refresh. #2

New Issue

MacKwnoX · 2026-11-13T15:47:27-04:00

MacKwnoX commented

2026-11-13 15:47:27 -04:00

I need to refresh the page in order for the totals at the top to show up correctly. I think they should be live (and or update on new batch).

AlexanderRozhenko referenced this issue from a commit

2026-11-13 15:58:37 -04:00

fix #2: header pill refreshes itself after swipes, undo and new batches

AlexanderRozhenko commented

2026-11-13 15:58:49 -04:00

Picked this up. Root cause: the header pill (live · fresh · new) and the list sub-line were populated by loadStats(), which ran exactly once at boot. Nothing re-fetched /api/stats afterwards, so every swipe/undo left the counters stale until a full page reload.

Fixed in 79e7a4f on dev:

the pill refreshes itself ~0.6s after any decision change (deck swipes, undo, dossier/list/matches edits) and whenever a new batch lands (section load or forge) — debounced and fire-and-forget, so a swipe never waits on it;
it also refreshes when the app returns to the foreground (catches new listings imported while it was open, e.g. the 08:30 run).

Checks:

Reproduced first on a copy of the live DB: swipes landed server-side in 0.2s while the pill stayed stale (2 swipes + undo, all stale pre-fix); with the fix all three update within ~0.6s, no reload.
app.selfcheck: 35/35.
fe_walk_v11: 91/91, including two new regression checks covering this bug.

Ready to deploy — reply deploy here and it ships; reply hold to pause.

Picked this up. Root cause: the header pill (`live · fresh · new`) and the list sub-line were populated by `loadStats()`, which ran exactly once at boot. Nothing re-fetched `/api/stats` afterwards, so every swipe/undo left the counters stale until a full page reload. Fixed in `79e7a4f` on `dev`: - the pill refreshes itself ~0.6s after any decision change (deck swipes, undo, dossier/list/matches edits) and whenever a new batch lands (section load or forge) — debounced and fire-and-forget, so a swipe never waits on it; - it also refreshes when the app returns to the foreground (catches new listings imported while it was open, e.g. the 08:30 run). Checks: - Reproduced first on a copy of the live DB: swipes landed server-side in 0.2s while the pill stayed stale (2 swipes + undo, all stale pre-fix); with the fix all three update within ~0.6s, no reload. - `app.selfcheck`: 35/35. - `fe_walk_v11`: 91/91, including two new regression checks covering this bug. Ready to deploy — reply `deploy` here and it ships; reply `hold` to pause.

MacKwnoX commented

2026-11-13 16:00:24 -04:00

Deploy

AlexanderRozhenko closed this issue

2026-11-13 16:01:45 -04:00

AlexanderRozhenko referenced this issue from a commit

2026-11-13 16:01:45 -04:00

merge: issue #2 fix (header pill liveness)

AlexanderRozhenko commented

2026-11-13 16:02:17 -04:00

Deployed — live on the stack (health 200).

Merge f252ea0 on main/release, new image built and re-raised by the unit (both containers under podman-stack-bike-tinder.service). Verified after cutover: /api/health 200, the served app carries the refresh logic, ledger untouched (609 live / 11 likes / 11 maybes / 122 nopes).

Counters now refresh ~0.6s after any swipe/undo/edit, when a new batch lands, and when the app returns to the foreground. Reload once on your phone to pick it up.

Deployed — live on the stack (health 200). Merge `f252ea0` on `main`/`release`, new image built and re-raised by the unit (both containers under `podman-stack-bike-tinder.service`). Verified after cutover: `/api/health` 200, the served app carries the refresh logic, ledger untouched (609 live / 11 likes / 11 maybes / 122 nopes). Counters now refresh ~0.6s after any swipe/undo/edit, when a new batch lands, and when the app returns to the foreground. Reload once on your phone to pick it up.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MacKwnoX/Bike-Tinder#2