Skip to content

desktop: gate instant uploads with a cached health probe#1917

Open
Peter7896 wants to merge 3 commits into
CapSoftware:mainfrom
Peter7896:peter7896/desktop-upload-health-speed-cache
Open

desktop: gate instant uploads with a cached health probe#1917
Peter7896 wants to merge 3 commits into
CapSoftware:mainfrom
Peter7896:peter7896/desktop-upload-health-speed-cache

Conversation

@Peter7896

@Peter7896 Peter7896 commented Jun 16, 2026

Copy link
Copy Markdown

/claim #73

This keeps the upload-speed and upload-health logic on one bounded path for Instant mode instead of doing a real object upload in the middle of the recording flow.

What changed:

  • add a desktop upload-health probe with a bounded payload, short timeout, and a 10 minute cache
  • use the cached result to cap Instant recording resolution before recording starts
  • add a web upload-health route that measures uploadability without leaving probe objects behind in storage
  • surface the health state in the desktop UI and add focused desktop/web coverage around tiering and byte limits

Follow-up hardening:

  • validate the server-reported receivedBytes before calculating throughput
  • subtract a same-route HEAD round trip estimate from the POST timing when it is safe to do so, reducing high-latency underestimation
  • short-circuit overlapping refresh probes so concurrent startup, interval, manual, or post-recording checks do not race the cache
  • avoid clearing the refresh spinner from non-refresh status reads
  • make the Content-Length check an explicit fast path while keeping stream-side byte counting as the enforcement boundary

Why this shape:

  • recording start only consumes cached state, so we do not wait on a fresh speed check after the user has already started recording
  • the health route exercises the upload path without introducing orphaned probe files or cleanup requirements
  • resolution gating stays conservative and only narrows Instant mode when the measured path says uploads are weak
  • the RTT adjustment avoids punishing high-latency links when actual upload throughput is still healthy

Validation:

  • git diff --check
  • pnpm exec biome check on touched TypeScript files
  • pnpm --dir apps/desktop exec vitest run src/utils/upload-health.test.ts
  • pnpm --dir apps/web exec vitest run tests/unit/desktop-upload-health.test.ts
  • cargo fmt --manifest-path apps/desktop/src-tauri/Cargo.toml --check
  • cargo test -j 1 -p cap-desktop upload_health --lib

@superagent-security

Copy link
Copy Markdown

Superagent didn't find any vulnerabilities or security issues in this PR.

Comment thread apps/desktop/src/routes/(window-chrome)/new-main/index.tsx
Comment thread apps/desktop/src/utils/upload-health.ts Outdated
Comment thread apps/desktop/src-tauri/src/upload_health.rs
Comment thread apps/desktop/src-tauri/src/upload_health.rs Outdated
Comment thread apps/desktop/src-tauri/src/upload_health.rs
Comment thread apps/web/app/api/desktop/[...route]/root.ts
Comment thread apps/desktop/src-tauri/src/upload_health.rs Outdated
Comment thread apps/desktop/src/routes/(window-chrome)/new-main/index.tsx
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant