When the app's daemon-event receiver falls behind, it silently skips lost events and continues without reconciling its session model.
Trigger and impact
Pause the store's event consumer while the client receives enough events to overflow its broadcast buffer. Include a session removal among the overwritten events, then resume consumption while keeping the connection open.
The store retains the removed session because the removal was lost. A missed initial update can similarly omit a newly created session. A later full update may repair an individual existing record, but it cannot reliably repair a missed removal; the stale state persists until a full hydration/reconnect.
This is an overload/recovery edge case, not a claim that ordinary terminal output routinely exhausts the buffer.
Evidence
- The client event channel has a finite capacity of 4096.
- route_message advances
last_seq and publishes each event to that channel. The transport has received the event even when an app subscriber subsequently loses it.
- The store event-consumer loop handles
RecvError::Lagged(_) with only continue. It neither requests a session list nor initiates replay.
- Full hydration occurs in connection-state handling; lag does not change connection state.
- hydrate already provides authoritative session/project replacement and selection reconciliation.
Expected behavior and regression coverage
Recognize lag as a model-consistency failure and arrange an authoritative resync. Coordinate the resync with subsequent events so a stale snapshot cannot overwrite newer changes, and coalesce repeated lag signals rather than launching unlimited refreshes.
Use a fake client/daemon to hold the store consumer, overflow the actual broadcast capacity with a removal among the lost events, and keep the socket connected. After recovery, verify the removed row is absent, new rows are present, and selection/residency are reconciled without restarting the app. Include events arriving during resync.
Validation: source-path review on main 1196d89; no live overload reproduction or new test was run.
When the app's daemon-event receiver falls behind, it silently skips lost events and continues without reconciling its session model.
Trigger and impact
Pause the store's event consumer while the client receives enough events to overflow its broadcast buffer. Include a session removal among the overwritten events, then resume consumption while keeping the connection open.
The store retains the removed session because the removal was lost. A missed initial update can similarly omit a newly created session. A later full update may repair an individual existing record, but it cannot reliably repair a missed removal; the stale state persists until a full hydration/reconnect.
This is an overload/recovery edge case, not a claim that ordinary terminal output routinely exhausts the buffer.
Evidence
last_seqand publishes each event to that channel. The transport has received the event even when an app subscriber subsequently loses it.RecvError::Lagged(_)with onlycontinue. It neither requests a session list nor initiates replay.Expected behavior and regression coverage
Recognize lag as a model-consistency failure and arrange an authoritative resync. Coordinate the resync with subsequent events so a stale snapshot cannot overwrite newer changes, and coalesce repeated lag signals rather than launching unlimited refreshes.
Use a fake client/daemon to hold the store consumer, overflow the actual broadcast capacity with a removal among the lost events, and keep the socket connected. After recovery, verify the removed row is absent, new rows are present, and selection/residency are reconciled without restarting the app. Include events arriving during resync.
Validation: source-path review on main
1196d89; no live overload reproduction or new test was run.