From ddc53dfb42cae9b3ac5a6e5e8f4fb8b1167accfb Mon Sep 17 00:00:00 2001 From: Dave Date: Tue, 24 Feb 2026 12:35:07 +0000 Subject: [PATCH] story-kit: create 136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag --- ...silently_drops_events_on_subscriber_lag.md | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 .story_kit/work/1_upcoming/136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag.md diff --git a/.story_kit/work/1_upcoming/136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag.md b/.story_kit/work/1_upcoming/136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag.md new file mode 100644 index 0000000..54fa3ba --- /dev/null +++ b/.story_kit/work/1_upcoming/136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag.md @@ -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