story-kit: create 136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag
This commit is contained in:
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
name: "Broadcast channel silently drops events on subscriber lag"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bug 136: Broadcast channel silently drops events on subscriber lag
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
The watcher broadcast channel (capacity 1024) silently drops events when a subscriber lags behind. In the WebSocket handler, the `Lagged` error is caught and handled with a bare `continue`, meaning the frontend never receives those state updates and falls out of sync.
|
||||||
|
|
||||||
|
## How to Reproduce
|
||||||
|
|
||||||
|
1. Open the web UI
|
||||||
|
2. Start agents that generate pipeline state changes
|
||||||
|
3. If the WebSocket consumer is momentarily slow (e.g., blocked on send), the broadcast subscriber falls behind
|
||||||
|
4. Lagged events are silently skipped
|
||||||
|
|
||||||
|
## Actual Result
|
||||||
|
|
||||||
|
Events are silently dropped with `continue` on `RecvError::Lagged`. The frontend misses state transitions and shows stale data.
|
||||||
|
|
||||||
|
## Expected Result
|
||||||
|
|
||||||
|
When a lag occurs, the system should recover by re-sending the full current pipeline state so the frontend catches up, rather than silently dropping events.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] Lagged broadcast events trigger a full state resync to the affected subscriber
|
||||||
|
- [ ] No silent event drops — lag events are logged as warnings
|
||||||
Reference in New Issue
Block a user