improve: desktop recording and editor responsiveness

[richiemcilroy]

Stopping a Studio recording opens the preparing editor in Tauri and GPUI while finalization continues. The timeline shows the confirmed playable portion, preview and audio become available progressively, and successful publication transfers the existing playback session into the ordinary editor. Cancellation, stale frames, recovery locks and empty-output muxer shutdown have regression coverage.

Also includes crop alignment and playhead improvements, the Windows hidden-window frame fix, development startup/cache improvements, and benchmark and regression harnesses.

Existing-link reuploads now transfer to a unique immutable object and atomically publish its key after validating the recording source, storage and active upload under database locks. Failed publication preserves the original media and supports retry; cancellation and superseded uploads cannot publish later. The share page and playlist endpoint resolve the committed output key through Storage before signing CDN URLs. Canonical thumbnail/preview invalidation remains best effort and does not gate the new MP4 URL. Both native clients request the replacement session at initiation. Clients can restart a legacy replacement once after the exact server conflict response, require a signed session for that restart, and reject changed source bytes before publication. Normal first uploads retain their existing protocol. The debug Stop benchmark requires an explicit recording opt-in and private app identity.

Latest local verification for the review fixes: web 3,120 passing tests (28 existing environment-dependent skips), web TypeScript, scoped Biome, Tauri 487 library plus six main tests, Tauri all-target check and strict Clippy, GPUI all-target check, and 1,005 passing GPUI tests (two existing benchmark ignores). Tauri binding generation is unchanged by these fixes and excluded from the ordinary test run. Current-head GitHub checks are tracked on this PR.

Prior feature verification included macOS editor 161 and recording/recovery 597 tests, Linux GPUI 1,052 and Tauri 536 function tests plus shared-library/integration scopes, Windows GPUI 970 and 1,314 library tests across eight crates, desktop frontend 473, and tooling 64. Counts are per listed scope; repeated runs are not additional coverage. The original PR head subsequently passed the configured macOS, Windows and Linux build/Clippy/sync checks.

The stopped sandbox campaign did not complete every requested Windows native integration, GPU, canonical and hardware scope. Existing GPUI and Linux export broad-Clippy baseline findings remain documented. These results are not packaged-release or zero-regression sign-off. Manual application testing, including audible continuity during preparation and editor handoff, remains outstanding. See the benchmark and verification report for exact scopes, comparisons and limitations.

Confidence Score: 5/5

The changes since the previous review appear safe to merge, with no outstanding blocking finding identified.

Summary

• Both native clients recognize the server’s exact replacement-restart conflict and retry once using a newly signed session.
• Replacement retries validate the original file identity, chunk contents, ordering, and complete byte coverage before publication.
• Tauri delays its completion event until video and thumbnail work succeed and cancellation is rechecked.
• Server regression coverage confirms that a legacy completion leaves the existing object untouched before a signed retry.
• The previously reported legacy replacement incompatibility is resolved; the other previous findings were manually resolved.

_{Reviews (3) · Last reviewed commit: "fix: restart legacy recording replacemen..."}

[superagent-security]

Superagent found 1 security concern(s).

[richiemcilroy]

hey @greptileai, please re-review the PR

[richiemcilroy]

hey @greptileai, please re-review the PR

[superagent-security]

Superagent found 1 security concern(s).

[superagent-security]

P2: Reupload cache invalidation failure is reported as success

CDN invalidation errors are reduced to warnings after the new upload is published.

Persist invalidation for retry or make failure actionable before reporting reupload success.

AI prompt

Check if this security scanner issue is valid. If so, understand the root cause and fix it. If appropriate, update or add tests. Keep the change focused and preserve intended behavior.

<file name="apps/web/app/api/upload/[...route]/multipart.ts">
<violation number="1" location="apps/web/app/api/upload/[...route]/multipart.ts:658">
<priority>P2</priority>
<title>Reupload cache invalidation failure is reported as success</title>
<evidence>The replacement transaction publishes the new source and deletes the upload row before `invalidateReuploadedVideo(video)` runs, but the invalidation promise is wrapped in `Effect.catchAll` that only logs a warning. A CDN invalidation failure therefore still returns the successful reupload response while an existing share URL may continue serving stale cached media.</evidence>
<recommendation>Make invalidation part of an explicitly recoverable publication state: either fail the reupload until invalidation succeeds, or persist a durable invalidation job/status and do not report the operation as fully published until retry succeeds. Add a test covering invalidation failure and subsequent retry.</recommendation>
</violation>
</file>

[richiemcilroy]

hey @greptileai, please re-review the PR