3.6 KiB
| status | trigger | created | updated |
|---|---|---|---|
| diagnosed | Controls and stems appear before JamTrack is synchronized | 2026-02-25T10:00:00Z | 2026-02-25T10:20:00Z |
Current Focus
hypothesis: CONFIRMED - The stems rendering condition at line 1406 includes 'idle' as a valid state, and downloadState.state defaults to 'idle'. Since handleJamTrackSelect dispatches UI state immediately without triggering loadJamTrack, the state never transitions from 'idle' to 'packaging', so stems render immediately. test: Verified by reading code flow expecting: N/A - root cause confirmed next_action: Document resolution
Symptoms
expected: Stems and controls should only appear AFTER JamTrack is synchronized with backend actual: Stems appear immediately in session screen when JamTrack is selected, before backend processing completes errors: None reported - visual UI issue reproduction: Select a JamTrack in session screen - stems immediately appear before server processing started: Existing behavior - partially fixed in 26-02 for player popup but not for session screen stems
Eliminated
- hypothesis: The rendering condition at line 1406 doesn't check downloadState evidence: It DOES check downloadState, but checks for 'synchronized' OR 'idle' - the problem is 'idle' is the default state timestamp: 2026-02-25T10:15:00Z
Evidence
-
timestamp: 2026-02-25T10:00:00Z checked: Research document .planning/research/JAMTRACK-LOADING.md found: Research already identified handleJamTrackSelect() at line 1165-1190 immediately dispatches setSelectedJamTrack(), setJamTrackStems(), setJamTrackData() without waiting for backend implication: UI state is set immediately causing premature rendering
-
timestamp: 2026-02-25T10:10:00Z checked: JKSessionScreen.js line 1405-1406 found: Condition IS checking downloadState but allows both 'synchronized' AND 'idle': (jamTrackDownloadState.state === 'synchronized' || jamTrackDownloadState.state === 'idle') implication: 'idle' means "not yet checked/synced" but is being treated as "ready to display"
-
timestamp: 2026-02-25T10:12:00Z checked: mediaSlice.js initial state (line 369-383) found: downloadState.state initial value is 'idle' implication: When JamTrack is selected, downloadState remains 'idle' until user clicks Play, which then triggers loadJamTrack which changes state to 'packaging'
-
timestamp: 2026-02-25T10:15:00Z checked: JKSessionScreen.js handleJamTrackSelect (line 1165-1190) found: Function only fetches metadata and dispatches UI state (setSelectedJamTrack, setJamTrackStems, setJamTrackData). It does NOT call loadJamTrack, so downloadState never transitions from 'idle'. implication: The fix must either: (1) remove 'idle' from valid render states, OR (2) change handleJamTrackSelect to trigger loadJamTrack BEFORE dispatching UI state
-
timestamp: 2026-02-25T10:17:00Z checked: JKSessionJamTrackPlayer.js line 680 found: Player controls also use same condition: (downloadState.state === 'idle' || downloadState.state === 'synchronized') implication: 26-02 fix addressed this by adding condition at line 680, but the same logical error exists - 'idle' should NOT be treated as ready
Resolution
root_cause: Two-part issue: (1) handleJamTrackSelect() dispatches UI state (setSelectedJamTrack, setJamTrackStems) immediately without triggering backend sync. (2) The rendering condition at line 1406 treats 'idle' as valid for showing stems, but 'idle' means "backend not yet checked" not "ready to display". Initial downloadState.state is 'idle', and it only changes to 'packaging'/'downloading'/'synchronized' when loadJamTrack is called (which happens on Play button click, not on selection). fix: verification: files_changed: []