[heidar-droid]

Fixes #3035.

Problem

In Instant mode, start_internal (apps/desktop-gpui/src/recording.rs) awaits prepare_instant_upload before the capture pipeline is built, but RecordingSession::start plays the start cue on the countdown regardless. When the create-video request is slow (a busy uplink while earlier takes are still uploading), the cue plays seconds before capture begins and the user's opening is lost.

From cap-gpui.log on 0.6.1 (cue → starting recording): 0.01–0.17 s with nothing uploading, 2.3–9.9 s once uploads were queued, once 102 s.

Fix

RecordingSession gets an engine_ready: watch::Sender<bool>:

• reset to false in start()
• set to true when the current generation's start resolves Ok (before it's stored as primed or activated)
• play_start_cue awaits wait_for(|ready| *ready) before playing the cue and arming the gate

So the cue, and the gate it arms, only fire once capture can actually begin. The countdown UI holds at its pre-start state meanwhile.

• Failed start: unchanged. The error branches call abort_start_cue, which aborts the waiting future.
• Studio mode: no network on start, so the pipeline is ready under the countdown as before.
• Stale generations: the existing generation guard returns before send_replace(true), so an old start can't release a new cue.

No new dependencies (tokio::sync::watch is already used in the crate).

🤖 Generated with Claude Code

Confidence Score: 4/5

This appears safe to merge, with non-blocking concerns about long-start lead-in and missing tests.

Findings

1.  Capture can precede the cue ▶
2.  Readiness wait has no tests ▶

Fix with agent prompt

### Issue 1
apps/desktop-gpui/src/session.rs:769
This wait can outlast the gate’s 20-second failsafe. The gate is created before `prepare_instant_upload`, so a slow request such as the reported 102-second case leaves it expired when capture starts. The first media check then opens the gate before the delayed cue finishes. The cue’s later `arm()` cannot replace that start time, so the saved recording can include the cue and unwanted lead-in.

Keep the gate closed through the readiness wait, and start its failsafe clock when capture is ready.

### Issue 2
apps/desktop-gpui/src/session.rs:769
The new wait has no test that exercises it. Existing countdown tests check `countdown_advance`, and the stop test installs an abort handle without starting `play_start_cue`. The timing behavior this fix depends on could regress without those tests catching it.

Add tests that hold readiness false, release it, and cancel or fail while waiting. Check that neither the cue nor the gate fires early and that an old attempt cannot release a new cue.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This change delays the start cue until capture startup succeeds.

• The recording start cue waits until the capture pipeline is ready.

_{Reviews (1) · Last reviewed commit: "fix(desktop-gpui): hold the start cue un..." · Reviewed by Greptile}

[vercel]

@heidar-droid is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Capture can precede the cue

This wait can outlast the gate’s 20-second failsafe. The gate is created before prepare_instant_upload, so a slow request such as the reported 102-second case leaves it expired when capture starts. The first media check then opens the gate before the delayed cue finishes. The cue’s later arm() cannot replace that start time, so the saved recording can include the cue and unwanted lead-in.

Keep the gate closed through the readiness wait, and start its failsafe clock when capture is ready.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/desktop-gpui/src/session.rs
Line: 769

Comment:
**Capture can precede the cue**

This wait can outlast the gate’s 20-second failsafe. The gate is created before `prepare_instant_upload`, so a slow request such as the reported 102-second case leaves it expired when capture starts. The first media check then opens the gate before the delayed cue finishes. The cue’s later `arm()` cannot replace that start time, so the saved recording can include the cue and unwanted lead-in.

Keep the gate closed through the readiness wait, and start its failsafe clock when capture is ready.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Readiness wait has no tests

The new wait has no test that exercises it. Existing countdown tests check countdown_advance, and the stop test installs an abort handle without starting play_start_cue. The timing behavior this fix depends on could regress without those tests catching it.

Add tests that hold readiness false, release it, and cancel or fail while waiting. Check that neither the cue nor the gate fires early and that an old attempt cannot release a new cue.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/desktop-gpui/src/session.rs
Line: 769

Comment:
**Readiness wait has no tests**

The new wait has no test that exercises it. Existing countdown tests check `countdown_advance`, and the stop test installs an abort handle without starting `play_start_cue`. The timing behavior this fix depends on could regress without those tests catching it.

Add tests that hold readiness false, release it, and cancel or fail while waiting. Check that neither the cue nor the gate fires early and that an old attempt cannot release a new cue.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!