Skip to content

Joining a Session late loses the driver list permanently, so the field never appears #79

Description

@jerome-queck

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)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is behaving wronglyready-for-agentFully specified, ready for an AFK agent

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions