wip: chat finalization paused - investigating repeated API requests

.planning/.continue-here.md

@@ -0,0 +1,204 @@
+---
+phase: 11-chat-finalization
+status: paused_for_investigation
+blocker: repeated_api_requests
+last_updated: 2026-01-31
+---
+
+<current_state>
+**Phase 11 UAT PAUSED** - Critical performance issue discovered during manual testing.
+
+**Issue:** Repeated API requests being made continuously after session screen loads (before clicking chat button). Same requests that occur on initial page load are repeating indefinitely.
+
+**Context:**
+- P0 bug fixed: session_id → music_session parameter (commit 5b940ae)
+- Code verified complete by gsd-verifier
+- Automated tests timing out (P2 - test infrastructure issue, not code)
+- During manual UAT, user discovered repeated request issue affecting session screen performance
+
+**Status:** Milestone v1.1 chat feature technically complete, but cannot approve UAT until repeated request issue is resolved.
+</current_state>
+
+<completed_work>
+## Phase 11: Chat Finalization
+
+- ✅ Plan 11-01: Error Handling, Accessibility & Polish (3 tasks) - COMPLETE
+  - Comprehensive error handling (red/yellow displays, retry button)
+  - Full accessibility (ARIA attributes, keyboard navigation, focus management)
+  - Edge case handling (empty states, validation, disconnection)
+
+- ✅ Plan 11-02: UAT & Final Integration Testing (2 of 3 tasks) - PAUSED
+  - Task 1: UAT checklist prepared (50+ test cases across 9 categories)
+  - Task 2: P0 bug fixed (session_id → music_session)
+  - Task 3: Manual UAT IN PROGRESS - paused due to repeated request issue
+
+## All Phases 6-10: COMPLETE
+- Phase 6: Session Chat Research & Design (2/2 plans)
+- Phase 7: Chat Infrastructure & State Management (3/3 plans)
+- Phase 8: Chat Window UI & Message Display (3/3 plans)
+- Phase 9: Message Composition & Sending (2/2 plans)
+- Phase 10: Read/Unread Status Management (1/1 plans)
+</completed_work>
+
+<remaining_work>
+## Immediate: Fix Repeated Request Issue
+
+**Priority:** P0 - Blocks milestone completion
+
+**Steps:**
+1. Diagnose repeated request pattern
+   - Capture HAR file or network log showing repeated requests
+   - Identify which API endpoints are being called repeatedly
+   - Determine request frequency and what triggers them
+   - Check if requests start immediately or after delay
+
+2. Investigate root cause
+   - Check if chat feature introduced polling/intervals
+   - Review useEffect hooks in JKSessionScreen for dependencies
+   - Check WebSocket reconnection logic
+   - Look for Redux thunks that auto-dispatch
+   - Check if existing session features (Backing Track, JamTrack, Metronome) have polling that's misbehaving
+
+3. Fix the issue
+   - Stop repeated requests
+   - Ensure fix doesn't break existing functionality
+   - Test all session features still work (chat, Backing Track, JamTrack)
+
+4. Complete Phase 11 UAT
+   - Verify repeated requests stopped
+   - Complete manual UAT checklist (50+ test cases)
+   - Verify no regressions
+   - Approve milestone
+
+## After Fix: Complete Milestone v1.1
+
+- Update STATE.md with "Phase 11 COMPLETE"
+- Update ROADMAP.md progress table
+- Verify all verification criteria met
+- Mark milestone v1.1 as SHIPPED
+</remaining_work>
+
+<decisions_made>
+## Phase 11 Decisions
+
+1. **Pause UAT for performance fix**: Repeated requests affect user experience and must be fixed before production approval
+2. **P0 bug fix successful**: session_id → music_session parameter corrected, chat messages now send successfully
+3. **Test infrastructure P2**: Playwright tests timing out is a test environment issue, not blocking deployment (manual UAT sufficient)
+4. **Manual UAT approach**: Given test infrastructure issues, comprehensive manual testing is primary validation method
+
+## Investigation Scope Decision
+
+**Scope:** Fix repeated request issue in session screen (may or may not be chat-related)
+
+**Out of scope (defer):**
+- Test infrastructure fixes (Playwright timeout issues)
+- Server-side read/unread tracking
+- File attachments, message editing, typing indicators
+- Other deferred features from Phase 6 design
+</decisions_made>
+
+<blockers>
+## P0: Repeated API Requests
+
+**Symptom:** After session screen loads, API requests repeat continuously (same requests as initial page load)
+
+**Discovery:** User noticed during manual UAT - occurred without clicking chat button
+
+**Impact:**
+- Performance degradation on session screen
+- Unnecessary backend load
+- Cannot approve milestone until resolved
+
+**Unknown:**
+- Which specific API endpoints are repeating
+- Request frequency (every second? every 500ms?)
+- Whether chat feature introduced this or exposed existing bug
+- Whether this affects only chat sessions or all sessions
+
+**Next Steps:**
+1. User to provide network HAR file or describe which requests repeat
+2. Investigate session screen component lifecycle
+3. Check for runaway polling/intervals
+4. Fix root cause
+5. Resume UAT
+</blockers>
+
+<context>
+## Mental State
+
+**What we were doing:**
+- Completing Phase 11 UAT (final validation before milestone approval)
+- Found and fixed P0 bug (parameter name mismatch causing 404 errors)
+- Started manual testing to validate the fix works
+- Discovered new P0 performance issue (repeated requests)
+
+**The vibe:**
+- Chat feature code is complete and verified
+- One critical bug fixed successfully
+- Very close to milestone completion
+- New blocker discovered during final testing (classic)
+- Need to pause and fix properly before proceeding
+
+**Key insight:**
+This repeated request issue may have existed before chat feature (chat just made it noticeable), or chat feature may have introduced it. Need to investigate whether:
+1. Chat components are polling unnecessarily
+2. Chat feature changed session screen render cycle
+3. Existing session features (Backing Track/JamTrack) have buggy polling
+4. WebSocket reconnection logic is broken
+
+## Technical Context
+
+**Files likely involved:**
+- `jam-ui/src/components/client/JKSessionScreen.js` - Main session container
+- `jam-ui/src/components/client/JKSessionChatWindow.js` - Chat window (if chat-related)
+- `jam-ui/src/hooks/useSessionWebSocket.js` - WebSocket connection
+- Any components with useEffect + setInterval/setTimeout
+- Redux thunks that auto-dispatch on state changes
+
+**Patterns to check:**
+- useEffect with missing dependencies → infinite re-renders
+- setInterval not cleaned up → multiple timers running
+- Redux thunk that dispatches itself → infinite loop
+- WebSocket reconnect logic → repeated connection attempts
+- Polling logic with wrong conditions → never stops polling
+
+**Testing approach:**
+1. Open DevTools Network tab
+2. Load session screen
+3. Don't interact with anything
+4. Watch for repeated requests
+5. Note which endpoints, frequency, and timing
+</context>
+
+<next_action>
+**When resuming:**
+
+1. **Start with diagnosis:**
+   ```
+   Ask user: "Can you describe which API requests are repeating?
+   - Which endpoints? (e.g., /api/sessions/X, /api/chat, /api/users/me)
+   - How often? (every second, every 500ms, constant?)
+   - Do they start immediately on page load or after a delay?
+   - Can you share a network HAR file or screenshot?"
+   ```
+
+2. **Once diagnosis is clear:**
+   - Use Grep to find setInterval/setTimeout in session screen components
+   - Check useEffect hooks for missing dependencies or cleanup
+   - Review chat component initialization for accidental polling
+   - Look for Redux thunks that re-dispatch on state changes
+
+3. **Fix pattern:**
+   - Identify root cause
+   - Apply minimal fix (stop the repeating)
+   - Test manually (verify requests stop)
+   - Verify no regressions (chat, Backing Track, JamTrack still work)
+   - Commit fix: `fix: stop repeated API requests on session screen`
+
+4. **Resume UAT:**
+   - Complete manual UAT checklist
+   - Approve Phase 11
+   - Complete milestone v1.1
+
+**Command to resume:** Just start the conversation by asking the user about the repeated requests.
+</next_action>