The ingestor was restarted five minutes into Sprint Qualifying. Records flowed immediately — 574
laps, 268 positions, 100 stints within a few minutes — but db.drivers.countDocuments({session_key: 11344}) stayed at 0, and the live dashboard rendered an empty grid for a Session that was
plainly producing data. FP1, joined before its start, has all 22.
The field never arrives, however long you wait.
Why
SignalR answers a Subscribe with a CompletionMessage carrying the current state of every
subscribed topic. That snapshot is where DriverList lives — F1 does not re-broadcast it on a
timer, only when a driver's details change.
The client throws that snapshot away
(fastf1_livetiming/signalrcore/client.py, in _on_message):
def _on_message(self, msg: list | CompletionMessage):
# Skip logic: Ignore data for 5s after (re)connect
if time.time() - self._connection_start_time < 5:
return
_on_connect sets _connection_start_time, then _send_subscribe sleeps 0.5s and subscribes. The
snapshot arrives well inside the five-second window and is discarded. Everything after it is a
delta.
So a connection opened before a Session starts sees DriverList as it is first published and is
fine. A connection opened after the Session is under way gets laps and positions with nobody to
attach them to, and a restart does not repair it — reconnecting fetches a fresh snapshot and
discards it by the same rule.
Why it matters more than it looks
Combined with #78, the stack can neither
be left running nor started late. #78 kills it during any gap between Sessions; this makes the
recovery from that failure useless. The two together leave a window of roughly ninety minutes
before a Session in which the stack must be started, and no way to tell you have missed it except
an empty screen.
It also silently degrades a capture that otherwise looks healthy: the Session's records are all
being written, so record counts, logs and container status all read normal.
Possible directions, none obviously right
- Do not discard the snapshot on first connect, only on reconnect. That is upstream's code and
ADR-0006 forbids
patching it, so this is an upstream report.
- Fill the field from the Stores. The driver list is a property of the weekend, not the
Session: 11343 and 11344 have the same 22 people. server/openf1/live-feed.ts could seed itself
from the Meeting's most recent Session rather than waiting for v1/drivers. This is ours to do
and needs a decision about a live view reading anything but the broker (ADR-0003).
- Say so on screen. Whatever else, a Live Session with records arriving and no field is a state
the dashboard should name, not draw as an empty grid.
A stopgap was used during Sprint Qualifying to make the Session watchable: FP1's 22 driver records
were re-stamped to session_key 11344 and published to the broker's v1/drivers topic, which the
feed picked up and rendered. Nothing was written to MongoDB and the capture was unaffected. That is
a demonstration that direction two works, not a proposal to keep it.
Assisted-by: Claude Opus 5 (reasoning: high)
The ingestor was restarted five minutes into Sprint Qualifying. Records flowed immediately — 574
laps, 268 positions, 100 stints within a few minutes — but
db.drivers.countDocuments({session_key: 11344})stayed at 0, and the live dashboard rendered an empty grid for a Session that wasplainly producing data. FP1, joined before its start, has all 22.
The field never arrives, however long you wait.
Why
SignalR answers a
Subscribewith aCompletionMessagecarrying the current state of everysubscribed topic. That snapshot is where
DriverListlives — F1 does not re-broadcast it on atimer, only when a driver's details change.
The client throws that snapshot away
(
fastf1_livetiming/signalrcore/client.py, in_on_message):_on_connectsets_connection_start_time, then_send_subscribesleeps 0.5s and subscribes. Thesnapshot arrives well inside the five-second window and is discarded. Everything after it is a
delta.
So a connection opened before a Session starts sees
DriverListas it is first published and isfine. A connection opened after the Session is under way gets laps and positions with nobody to
attach them to, and a restart does not repair it — reconnecting fetches a fresh snapshot and
discards it by the same rule.
Why it matters more than it looks
Combined with #78, the stack can neither
be left running nor started late. #78 kills it during any gap between Sessions; this makes the
recovery from that failure useless. The two together leave a window of roughly ninety minutes
before a Session in which the stack must be started, and no way to tell you have missed it except
an empty screen.
It also silently degrades a capture that otherwise looks healthy: the Session's records are all
being written, so record counts, logs and container status all read normal.
Possible directions, none obviously right
ADR-0006 forbids
patching it, so this is an upstream report.
Session: 11343 and 11344 have the same 22 people.
server/openf1/live-feed.tscould seed itselffrom the Meeting's most recent Session rather than waiting for
v1/drivers. This is ours to doand needs a decision about a live view reading anything but the broker (ADR-0003).
the dashboard should name, not draw as an empty grid.
A stopgap was used during Sprint Qualifying to make the Session watchable: FP1's 22 driver records
were re-stamped to
session_key11344 and published to the broker'sv1/driverstopic, which thefeed picked up and rendered. Nothing was written to MongoDB and the capture was unaffected. That is
a demonstration that direction two works, not a proposal to keep it.
Assisted-by: Claude Opus 5 (reasoning: high)