Meeting 2 recording blocked while Meeting 1 is processing

[hyper-charlie]

Issue

When manually transitioning between back-to-back meetings, the processing of the first meeting prevents the second meeting from starting recording.

Steps to Reproduce

1. Finish recording Meeting 1
2. Immediately start Meeting 2 while Meeting 1 is still being processed
3. Attempt to begin recording for Meeting 2

Expected Behavior

Meeting 2 recording should start immediately, with Meeting 1's processing happening in the background.

Actual Behavior

Meeting 2 fails to start recording because the app is still processing Meeting 1. Recording is blocked until Meeting 1 processing completes.

Environment

• Platform: macOS
• OS Version: macOS 15.7.3 Sequoia
• App Version: 1.0.17
• Hardware: M4 Max, 128GB RAM
• Build: 866a098

User Impact

• Blocks back-to-back meeting recordings
• Forces users to wait for processing before starting new recordings

[devin-ai-integration]

Analysis: Recording blocked during back-to-back meetings

Root Cause

The app has a single RootActor that manages one session at a time. Both the backend state machine and the frontend Zustand store enforce mutual exclusion — a new session cannot start until the previous session's teardown is fully complete.

Where the blocking happens

Backend — RootActor (crates/listener-core/src/actors/root.rs)

The RootActor holds supervisor: Option<ActorCell>. In start_session_impl (line 155), if state.supervisor.is_some(), it immediately returns StartSessionError::SessionAlreadyRunning. The supervisor is only cleared to None in handle_supervisor_evt after the session supervisor actor has fully terminated.

Shutdown sequence (crates/listener-core/src/actors/session/supervisor/children.rs)

shutdown_children (line 214) stops child actors sequentially using stop_and_wait with a 30-second timeout per child:

1. Source actor → stops
2. Listener actor → stops
3. Recorder actor → stops (this is the bottleneck)

The recorder's post_stop (crates/listener-core/src/actors/recorder/mod.rs, line 115) calls finalize_disk_sink which does:

• WAV writer flush and finalize
• WAV→MP3 encoding via hypr_mp3::encode_wav (CPU-intensive, can take several seconds for long recordings)
• sync_file and sync_dir for durability

Until all three children terminate → the session supervisor terminates → RootActor receives the ActorTerminated supervision event → clears state.supervisor → a new StartSession can proceed.

Frontend — Zustand listener store (apps/desktop/src/store/zustand/listener/general.ts, line 76)

if (currentLive.loading || currentLive.status !== "inactive") {
  console.warn("[listener] cannot start live session while another session is running");
  return false;
}

While the backend is finalizing, the frontend is in "finalizing" status (set via markLiveFinalizing), so this guard rejects any new start attempt.

Frontend — UI button (apps/desktop/src/session/components/shared.tsx, line 83)

const active = sessionMode === "active" || sessionMode === "finalizing";
const shouldRender = !active && !generating;

During finalization, the listen button is hidden entirely, so the user can't even attempt to start a new session.

Key files involved

Area	File	Purpose
State machine	crates/listener-core/src/actors/root.rs	Single-session gate (lines 155-157)
Shutdown order	crates/listener-core/src/actors/session/supervisor/children.rs	Sequential child shutdown (lines 214-233)
Recorder teardown	crates/listener-core/src/actors/recorder/disk.rs	WAV→MP3 encoding in finalize_disk_sink (lines 161-184)
Frontend guard	apps/desktop/src/store/zustand/listener/general.ts	Rejects start while status ≠ inactive (line 76)
Frontend UI	apps/desktop/src/session/components/shared.tsx	Hides button during finalizing (line 83)
Lifecycle events	plugins/listener/src/runtime.rs	Tray icon state during finalization (line 41)

Potential approaches

1. Decouple finalization from session lifecycle: After capturing the audio data, immediately release the RootActor's lock (clear supervisor and emit Inactive) and offload the expensive finalization work (MP3 encoding, file sync) to a background task pool. This would let a new session start while the previous one's audio is still being encoded.

2. Two-phase shutdown: Split the shutdown into "stop recording" (fast — stops audio capture and returns the actor to an available state) and "finalize" (slow — encoding, cleanup). The RootActor would transition to Inactive after the first phase.

3. Frontend-only partial fix: Allow the frontend to accept a new start call while in "finalizing" state by queuing it. Once the backend emits Inactive, automatically start the queued session. This is simpler but still has a delay (user waits for the encoding to finish before audio capture begins).

Approach 1 or 2 would fully resolve the user-reported issue. The key constraint is ensuring the encoded audio file is safely written before the session directory is accessed for upload/sync.