Zackriya-Solutions/meetily · warning · anyhow::Error

Recording not active

Error message

Recording not active

What it means

The attempt_device_reconnect Tauri command requires an active recording: the global RECORDING_MANAGER must contain a manager. The error fires from either the fast pre-check before spawn_blocking or the check inside block_on, and means recording was never started or has already been torn down.

Source

Thrown at frontend/src-tauri/src/audio/recording_commands.rs:1197

        _ => return Err(format!("Invalid device type: {}", device_type)),
    };

    // Check if recording is active
    {
        let manager_guard = RECORDING_MANAGER.lock().unwrap();
        if manager_guard.is_none() {
            return Err("Recording not active".to_string());
        }
    } // Release lock

    // Spawn blocking task to handle the async reconnection
    let result = tokio::task::spawn_blocking(move || {
        tokio::runtime::Handle::current().block_on(async {
            let mut manager_guard = RECORDING_MANAGER.lock().unwrap();
            if let Some(manager) = manager_guard.as_mut() {
                manager.attempt_device_reconnect(&device_name, monitor_type).await
            } else {
                Err(anyhow::anyhow!("Recording not active"))
            }
        })
    })
    .await
    .map_err(|e| format!("Task join error: {}", e))?;

    match result {
        Ok(success) => {
            if success {
                info!("✅ Manual reconnection successful");
            } else {
                warn!("❌ Manual reconnection failed - device not available");
            }
            Ok(success)
        }
        Err(e) => {
            error!("Manual reconnection error: {}", e);
            Err(e.to_string())

View on GitHub (pinned to 0281737d87)

Solutions

1. Drive Reconnect button visibility from backend recording-state events or the is_recording command, not cached frontend state
2. If the recording already stopped, call start_recording again instead of attempt_device_reconnect
3. Poll get_reconnection_status before invoking the manual reconnect to confirm a live session

Example fix

// before (frontend)
await invoke('attempt_device_reconnect', { deviceName, monitorType });

// after - confirm a live recording first
if (!(await invoke<boolean>('is_recording'))) {
  showToast('Recording has stopped - start a new recording instead');
  return;
}
await invoke('attempt_device_reconnect', { deviceName, monitorType });

// Frontend: confirm a live recording before manual reconnect
const recording = await invoke<boolean>('is_recording');
if (!recording) {
  // hide Reconnect, offer Start Recording instead
}

Catch the 'Recording not active' string error from the invoke and map it to a UI hint ('Recording has stopped - start a new recording'), not a generic failure toast.

When it happens

Trigger: Frontend fires attempt_device_reconnect after a disconnect flow already stopped the recording; user clicks Reconnect after clicking Stop; UI recording state is stale because it missed a recording-stopped event; command invoked from a script outside a live session.

Common situations: Bluetooth device loss triggers auto-stop but the UI still shows a Reconnect button; rapid stop-then-reconnect race; frontend state cached across meeting switches.

Related errors

• Cannot pause when not recording
• Recording is already paused
• Cannot resume when not recording
• Recording is not paused
• Import already in progress

AI-assisted analysis of Zackriya-Solutions/meetily@0281737d87 (2026-08-16). Data as JSON: /api/errors/8d99b7c1ae414199. Report an issue: GitHub.