Race feed freezes when the local racer's lap goes down #14

New issue

Closed

opened 2026-10-19 13:05:06 +00:00 by mintopia · 2 comments

mintopia commented

2026-10-19 13:05:06 +00:00

Owner

Problem

race::Feed::update (src/host/race_feed.cpp) treats any drop of the local racer's lap (me->lap < prev_lap_) as race teardown and returns without publishing. But the game itself can lower a racer's lap mid-race (driving back over the start/finish line, or being reset behind it): the lap byte at racer +0xf44 goes down and the HUD shows it too.

Evidence, capture work/ws-capture/runs/20261019-112144 (2-player LAN, USA_LA_River_3, offsets in seconds from alpha's connect):

alpha's feed sees bravo's lap go 2→1 at 374.6, 1→2 at 411.7, 2→1 at 479.0.
bravo's own HUD shows Laps 1/3 in bravo/client-r180.png and client-r300.png, so the drop is real in bravo's game, not a network glitch.
bravo's own feed (bravo.jsonl) publishes nothing for itself after 374.4 except while its lap is back at 2 (411.7–479); race_time freezes (final race_result.time 161 at 573 although the race ran ~370 s).

What to build

Tell real teardown apart from a game-side lap decrease. Teardown is the racer list going away or lap dropping to 0/below 1 (me->lap < 1 is already handled above); a decrease that stays ≥ 1 is a normal update. Keep the race_time accumulator correct across a decrease (it currently adds the lap timer at each lap change when the timer drops; make sure a decrease followed by a re-increment does not double count or lose time).

Document in docs/state-websocket.md that a racer's lap can go down during a race (the game's own counter).

Acceptance criteria

Unit test in tests/race_feed_test.cpp: local lap 2→1→2 mid-race keeps publishing lap, standings, speeds, and race_time keeps increasing
The existing teardown case (racers reset at the end of a race) still clears/keeps keys as today
docs/state-websocket.md notes that lap can decrease
Verified on BLUR_ENGINE=recomp

## Problem `race::Feed::update` (`src/host/race_feed.cpp`) treats any drop of the **local** racer's lap (`me->lap < prev_lap_`) as race teardown and returns without publishing. But the game itself can lower a racer's lap mid-race (driving back over the start/finish line, or being reset behind it): the lap byte at racer `+0xf44` goes down and the HUD shows it too. Evidence, capture `work/ws-capture/runs/20261019-112144` (2-player LAN, `USA_LA_River_3`, offsets in seconds from alpha's connect): - alpha's feed sees bravo's lap go 2→1 at 374.6, 1→2 at 411.7, 2→1 at 479.0. - bravo's own HUD shows `Laps 1/3` in `bravo/client-r180.png` and `client-r300.png`, so the drop is real in bravo's game, not a network glitch. - bravo's own feed (`bravo.jsonl`) publishes nothing for itself after 374.4 except while its lap is back at 2 (411.7–479); `race_time` freezes (final `race_result.time` 161 at 573 although the race ran ~370 s). ## What to build Tell real teardown apart from a game-side lap decrease. Teardown is the racer list going away or lap dropping to 0/below 1 (`me->lap < 1` is already handled above); a decrease that stays ≥ 1 is a normal update. Keep the `race_time` accumulator correct across a decrease (it currently adds the lap timer at each lap change when the timer drops; make sure a decrease followed by a re-increment does not double count or lose time). Document in `docs/state-websocket.md` that a racer's `lap` can go down during a race (the game's own counter). ## Acceptance criteria - [ ] Unit test in `tests/race_feed_test.cpp`: local lap 2→1→2 mid-race keeps publishing `lap`, `standings`, `speeds`, and `race_time` keeps increasing - [ ] The existing teardown case (racers reset at the end of a race) still clears/keeps keys as today - [ ] `docs/state-websocket.md` notes that `lap` can decrease - [ ] Verified on `BLUR_ENGINE=recomp`

mintopia added this to the Timing tower telemetry milestone

2026-10-19 13:05:06 +00:00

mintopia referenced this issue

2026-10-19 13:05:07 +00:00

Per-racer lap times and a sub-second race clock in the feed #15

mintopia added a new dependency

2026-10-19 13:05:08 +00:00

#15 Per-racer lap times and a sub-second race clock in the feed

mintopia added the

ready-for-agent

label

2026-10-19 13:05:09 +00:00

mintopia self-assigned this

2026-10-19 13:06:04 +00:00

mintopia commented

2026-10-19 13:07:26 +00:00

Author

Owner

Fix: Feed::update now treats a local lap decrease as teardown only after the player has finished (finished_); a mid-race decrease (still >= 1) is a normal update, and the race_time accumulator handles decrease/re-increment (timer-drop rule unchanged). Added unit test (lap 2->1->2 keeps lap/standings/speeds, race_time keeps increasing); teardown tests still pass; documented in docs/state-websocket.md. NOT verified on BLUR_ENGINE=recomp (no game/runtime in this unattended session) - needs a live 2-player run.

Fix: `Feed::update` now treats a local lap decrease as teardown only after the player has finished (`finished_`); a mid-race decrease (still >= 1) is a normal update, and the `race_time` accumulator handles decrease/re-increment (timer-drop rule unchanged). Added unit test (lap 2->1->2 keeps lap/standings/speeds, race_time keeps increasing); teardown tests still pass; documented in docs/state-websocket.md. NOT verified on BLUR_ENGINE=recomp (no game/runtime in this unattended session) - needs a live 2-player run.

mintopia closed this issue

2026-10-19 13:08:40 +00:00

mintopia commented

2026-10-19 13:08:40 +00:00

Author

Owner

Completed and merged by Harmonic (task 16).

mintopia referenced this issue from a commit

2026-10-19 19:54:20 +00:00

Race feed: only treat a local lap drop as teardown after the player finished (#14)