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