dave/storkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity

story-kit: queue 137_bug_lozengeflycontext_animation_queue_race_condition_on_rapid_updates for QA

Browse Source
This commit is contained in:
Dave
2026-02-24 13:05:17 +00:00
parent 88aa2de2ad
commit 71e07041cf
2 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
.story_kit/work/3_qa/137_bug_lozengeflycontext_animation_queue_race_condition_on_rapid_updates.md Normal file
View File

@@ -0,0 +1,29 @@
---
name: "LozengeFlyContext animation queue race condition on rapid updates"
---
# Bug 137: LozengeFlyContext animation queue race condition on rapid updates
## Description
In LozengeFlyContext.tsx, the useEffect that executes animations clears pending action refs at the start of each run. When rapid pipeline updates arrive, useLayoutEffect queues actions into refs, but the useEffect can clear them before they're processed. This breaks the diffing chain and causes the UI to stop reflecting state changes.
## How to Reproduce
1. Open the web UI
2. Trigger several pipeline state changes in quick succession (e.g., start multiple agents)
3. Observe that lozenge animations stop firing after a few updates
4. The pipeline state in the server is correct but the UI is stale
## Actual Result
The useEffect clears pendingFlyInActionsRef before processing, racing with useLayoutEffect that queues new actions. After a few rapid updates the animation queue gets into an inconsistent state and stops processing.
## Expected Result
Animation queue should handle rapid pipeline updates without losing actions or breaking the diffing chain.
## Acceptance Criteria
- [ ] No animation actions are lost during rapid pipeline updates
- [ ] Lozenge fly animations remain functional through sustained agent activity

30
.story_kit/work/3_qa/138_bug_no_heartbeat_to_detect_stale_websocket_connections.md
View File

@@ -1,30 +0,0 @@
---
name: "No heartbeat to detect stale WebSocket connections"
---
# Bug 138: No heartbeat to detect stale WebSocket connections
## Description
The WebSocket client in frontend/src/api/client.ts only reconnects when the onclose event fires. If the connection half-closes (appears open but stops receiving data), onclose never fires and reconnection never happens. There is no ping/pong heartbeat mechanism to detect this state.
## How to Reproduce
1. Open the web UI and establish a WebSocket connection
2. Wait for a network disruption or half-close scenario
3. The connection appears open but stops delivering messages
4. No reconnection is attempted
## Actual Result
The frontend keeps a dead WebSocket open indefinitely with no way to detect it has stopped receiving data. UI becomes permanently stale until manual refresh.
## Expected Result
A heartbeat mechanism should detect stale connections and trigger automatic reconnection.
## Acceptance Criteria
- [ ] WebSocket client implements a periodic heartbeat/ping to detect stale connections
- [ ] Stale connections are automatically closed and reconnected
- [ ] Server responds to ping frames or implements server-side keepalive