don't abort encoding if capurer stop fails

[Brendonovich]

Summary by CodeRabbit

• Bug Fixes

  • Improved video recording reliability: capture and stop operations are handled separately so muxing no longer forces failures when stopping the video source fails. Recording tasks now complete cleanup more gracefully, reducing aborted recordings.

• Refactor

  • Split video capture lifecycle into its own background task for more robust handling of start/stop operations.

[coderabbitai]

Walkthrough

Shifts video source lifecycle management into a new "capture-video" task that starts and later stops the video source; the muxing path no longer starts or stops the video source and runs until cancellation, relying on the capture task to handle start/stop and log stop errors.

Changes

Cohort / File(s)	Change Summary
Video capture lifecycle refactor crates/recording/src/output_pipeline/core.rs	Added a separate capture-video task that starts the video source, awaits cancellation, then attempts to stop it and logs errors; removed the initial start and the explicit stop of the video source from the muxing path so mux-video now processes frames until cancellation.

Sequence Diagram(s)

sequenceDiagram
    participant Capture as Capture Task
    participant Source as Video Source
    participant Muxer as Muxing Path
    participant Cancel as Cancellation

    rect rgb(235, 245, 255)
    Note over Capture,Source: New capture task lifecycle
    Capture->>Source: start()
    Capture->>Cancel: await cancellation
    Cancel-->>Capture: cancel
    Capture->>Source: stop()
    Source-->>Capture: ok / error (logged)
    end

    rect rgb(245, 255, 235)
    Note over Muxer: Muxing path behavior
    Muxer->>Muxer: process frames until cancellation
    Cancel-->>Muxer: cancel
    Muxer-->>Muxer: terminate without stopping Source
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Remove todo!() in pause/resume and fix timing on macos #1153 — modifies video source stop handling in the same file; related to lifecycle/stop error handling changes.

Poem

🐇 I started the capture, I tended the stream,

I waited for cancel in a soft silver gleam.
When stopping went sideways I logged but stayed kind,
The muxer kept dancing, no panic in mind.
Hooray for calm shutdowns — a rabbit-approved find! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The PR title "don't abort encoding if capurer stop fails" directly and specifically describes the main change in the changeset. The modification shifts video source lifecycle management to a separate task and allows the encoding process to continue gracefully when the video source fails to stop, instead of aborting. The title is concise, clear, and avoids vague language, making it easily understandable in git history. There is a minor spelling inconsistency ("capurer" instead of "capturer"), but this does not impede clarity.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch silent-fail-capturer-stop

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7ff2a96 and 432af2e.

📒 Files selected for processing (1)

• crates/recording/src/output_pipeline/core.rs (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• crates/recording/src/output_pipeline/core.rs

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: Build Desktop (x86_64-pc-windows-msvc, windows-latest)
• GitHub Check: Build Desktop (aarch64-apple-darwin, macos-latest)
• GitHub Check: Analyze (rust)

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

crates/recording/src/output_pipeline/core.rs (1)

437-437: Optional: Remove trailing semicolon for conventional style.

The semicolon after the closing brace is valid but unconventional in Rust. Most idiomatic Rust code omits it.

     if let Err(e) = video_source.stop().await {
         error!("Video source stopped with error: {e:#}");
-    };
+    }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 58c343d and 7ff2a96.

📒 Files selected for processing (1)

• crates/recording/src/output_pipeline/core.rs (1 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

**/*.rs

📄 CodeRabbit inference engine (AGENTS.md)

**/*.rs: Format Rust code using rustfmt and ensure all Rust code passes workspace-level clippy lints.
Rust modules should be named with snake_case, and crate directories should be in kebab-case.

Files:

• crates/recording/src/output_pipeline/core.rs

crates/*/src/**/*

📄 CodeRabbit inference engine (AGENTS.md)

Rust crates should place tests within the src/ and/or a sibling tests/ directory for each crate inside crates/*.

Files:

• crates/recording/src/output_pipeline/core.rs

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: Build Desktop (aarch64-apple-darwin, macos-latest)
• GitHub Check: Build Desktop (x86_64-pc-windows-msvc, windows-latest)
• GitHub Check: Analyze (rust)

🔇 Additional comments (2)

crates/recording/src/output_pipeline/core.rs (2)

435-437: Good change - consistent error handling with audio sources.

This change aligns video source stop error handling with the audio source pattern (lines 512-514), where stop errors are intentionally ignored to allow graceful pipeline completion. By logging but not propagating the error, the muxer cleanup at line 439 can proceed even if the video source fails to stop cleanly, which prevents cascading failures during shutdown.

---

435-437: Remove or reconsider the review comment; the error-handling pattern is appropriate and doesn't pose resource leak risks.

The verification reveals that only platform-specific VideoSource implementations (Windows/macOS) override stop() with actual cleanup logic. Both implementations use additional mechanisms to ensure cleanup proceeds even if stop() errors:

• macOS: calls cancel_token.cancel() regardless of capturer.stop() result
• Windows: control thread management ensures cleanup through separate async coordination

ChannelVideoSource uses the default no-op stop() and relies entirely on Rust ownership for resource cleanup (task drops naturally when receiver is closed).

Logging errors while continuing is a standard graceful shutdown pattern here—individual source failures don't prevent overall pipeline cleanup.

Likely an incorrect or invalid review comment.