Audio doesn't auto-transition between back-to-back meetings

[hyper-charlie]

Issue

When attending back-to-back meetings, audio doesn't automatically transition from one meeting to the next.

Steps to Reproduce

1. Schedule two meetings with no gap between them (or minimal gap)
2. Attend the first meeting with Hyprnote recording
3. When the first meeting ends and the second begins, observe audio behavior

Expected Behavior

Audio input should seamlessly switch to the new meeting and continue recording without manual intervention.

Actual Behavior

Audio stops recording or fails to switch to the second meeting automatically. User must manually switch, but this triggers a secondary issue (see related issues).

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 workflow for users with consecutive meetings
• Requires manual intervention to continue recording

[devin-ai-integration]

Codebase Exploration: Audio Session Transition for Back-to-Back Meetings

After exploring the codebase, here's what I found regarding why audio doesn't auto-transition between consecutive meetings.

Root Cause

The system currently has no session transition mechanism. It assumes only one session at a time, and when a new meeting starts while one is still active, every layer blocks the new session from starting:

1. Backend hard block — plugins/listener/src/actors/root.rs:138-141

if state.supervisor.is_some() {
    tracing::warn!("session_already_running");
    return false;
}

start_session_impl rejects any new session if a supervisor (i.e., an active session) already exists. There is no "replace" or "transition" variant — just a hard refusal.

2. Frontend auto-start guard — apps/desktop/src/components/main/body/sessions/index.tsx:230-232

if (listenerStatus !== "inactive") {
  return;
}

When a new session tab opens with autoStart: true, the TabContentNote component checks listener status. If the previous session is still "active" or "finalizing", auto-start is silently skipped and the hasAttemptedAutoStart ref prevents retries.

3. Notification handler doesn't stop existing sessions — apps/desktop/src/components/event-listeners.tsx:81-100

When a user accepts a notification for an upcoming meeting (notification_confirm / notification_accept), it opens a new session tab with { autoStart: true } but never checks if another session is already recording. The new tab opens, but start is blocked by point #2 above.

4. Zustand store start() doesn't handle transitions — apps/desktop/src/store/zustand/listener/general.ts:131-395

The start function goes straight to startSessionEffect(params) without first stopping any existing session.

Relevant Files

File	Role
plugins/listener/src/actors/root.rs	Backend actor managing session lifecycle (start/stop/state)
plugins/listener/src/actors/session.rs	Session supervisor spawning (SourceActor, ListenerActor, RecorderActor)
plugins/listener/src/fsm.rs	FSM states: Active, Inactive, Finalizing
apps/desktop/src/store/zustand/listener/general.ts	Frontend listener state management (start, stop, getSessionMode)
apps/desktop/src/components/main/body/sessions/index.tsx	TabContentNote auto-start logic (lines 220-249)
apps/desktop/src/components/event-listeners.tsx	Notification → auto-start trigger flow
apps/desktop/src/services/event-notification/index.ts	Periodic check for upcoming calendar events, triggers notifications
apps/desktop/src/hooks/useStartListening.ts	Hook that assembles SessionParams and calls start()

Architecture Context

The listener plugin uses an actor-based architecture (ractor):

• RootActor — top-level, owns RootState with a single supervisor: Option<ActorCell> and session_id: Option<String>
• Session supervisor → SourceActor (audio capture) + ListenerActor (STT streaming) + RecorderActor (WAV recording)
• The supervisor uses RestForOne strategy with max 3 restarts in 15 seconds

The single-supervisor design in RootState inherently limits the system to one active session.

Potential Approaches

1. Add a TransitionSession message to RootActor (recommended): A new RootMsg variant that atomically stops the current session, waits for finalization, then starts the new one. This keeps the transition logic in the backend where it's most reliable.

2. Frontend stop-then-start in auto-start logic: In TabContentNote (index.tsx), when autoStart is true and listenerStatus !== "inactive", call stop() first, then wait for "inactive" status before calling startListening(). Simpler but may have race conditions.

3. Notification handler checks for active session: In event-listeners.tsx, when handling notification_confirm/notification_accept, check if a session is active, stop it, wait for inactive, then open the new tab with autoStart: true.

Approach #1 is the most robust since it handles the transition atomically in the backend actor. Approaches #2/#3 could work as a quicker fix but would need careful handling of the "finalizing" state and the hasAttemptedAutoStart ref preventing retries.

Additional Context

• The issue mentions a "secondary issue" when manually switching — this is likely because start is called while the previous session is still "finalizing" (the stop → inactive transition involves waiting for the RecorderActor to complete its post_stop, which can take up to 5 seconds via wait_for_actor_shutdown polling 50 times at 100ms intervals).
• The autoStart flag was added in commit 8a0ee8d63 ("Add auto start from notification Add auto start from notification #2681") but didn't account for back-to-back scenarios.
• The notification system checks for upcoming events every 30 seconds (EVENT_NOTIFICATION_INTERVAL) and notifies 5 minutes before start (NOTIFY_WINDOW_MS), so there's a window where the notification fires while the previous meeting's session is still active.
• The stop_session_impl in root.rs sets state.finalizing = true and calls supervisor.stop(None) — the Inactive event is only emitted when the supervisor actually terminates (via handle_supervisor_evt), creating a gap during which no new session can start.

[yujonglee]

Related: #4492