Repository navigation
Implement speed test and health check for Cap desktop app #73
Description
Activity
- changed the title
[-]Implement speed test and health check for Cap app[/-][+]Implement speed test and health check for Cap desktop app[/+]on Aug 12, 2024 /bounty $500
/attempt #73
Algora profile Completed bounties Tech Active attempts Options @varshith257 8 bounties from 4 projects TypeScript, GoCancel attempt @richiemcilroy Could I get this assigned? I would like to work on this and complete this ASAP
/attempt #73
Algora profile Completed bounties Tech Active attempts Options @onyedikachi-david 5 bounties from 2 projects JavaScript, ShellCancel attempt /attempt #73
Options
💡 @webbdays submitted a pull request that claims the bounty. You can visit your bounty board to reward.
Sorry for the slow progress here. Over the last couple of months we have completely redeveloped the app from the ground up, leading to the launch of Cap v0.3.0. It's a different architecture (Tauri v2 + SolidJS).
- added a commit that references this issue
on Mar 14, 2026 /attempt #73
Focused implementation plan (Tauri v2 + SolidJS architecture):
- Add a startup upload health-check flow in desktop that does a lightweight signed upload probe and surfaces clear UI state (ok / degraded / failed).
- Add a one-shot pre-recording network probe (no re-check during active recording) and map probe tiers to capture quality presets.
- Wire probe result into recording setup so quality is selected before recording starts.
- Add small, deterministic tests around threshold mapping + fallback behavior, and a manual validation checklist for real-network scenarios.
I will ship this in scoped increments so it is reviewable and easy to extend.
Submitted PR #1827 for this bounty. It adds a one-shot pre-recording upload probe, adaptive instant resolution cap, and in-app probe status indicator.
/attempt #73
Is the reward for #73 still available, and would you consider a separate USD75 completion milestone on your preferred existing PR?
The existing review on #1917 identifies an in-flight upload probe continuing after recording starts. I would first reproduce that reported race, then wire recording startup to cancel/join the probe and add a deterministic regression covering recording becoming pending during the upload POST. This is the existing reviewer's finding, not a new discovery, and I would credit both the implementation and review.
I use Codex assistance with review and tests. Before implementation, could you confirm the preferred branch, whether this paid split is useful, and whether an India-based contributor can receive the award through Algora or PayPal? I would also establish the required desktop validation environment before agreeing delivery; the existing PR reports missing FFmpeg headers on Windows.
/attempt #73
@richiemcilroy, one concrete acceptance question after reviewing @stffinfcti's #2322 at
37edc2de284514888373dbf083ef7b9bb195f243:The original issue asks whether uploading a recording is possible. The proposed upload-health endpoint authenticates via the API contract and counts a bounded request body without writing to object storage. That avoids orphaned test uploads, but a successful response establishes app-API reachability, not that the recording's storage destination or upload-signing path is functioning.
Should acceptance require detecting an unavailable/misconfigured storage destination too, or is authenticated app-API reachability intentionally the desired scope? If storage is in scope, a useful additional acceptance case would be: app API remains reachable while the recording upload destination fails; the health indicator should reflect whichever guarantee is agreed. A storage probe would also need an agreed cleanup policy.
I also confirmed that the current #2322 source already addresses the earlier review's recording-admission lock and retained-speed-cap points; I would not duplicate those as new findings. Credit for the implementation belongs to its author. This is an AI-assisted source review (Devin/Codex), not a runtime validation or a claim on the existing author's work.
If a separate storage-path validation/test contribution would be useful, is the advertised bounty still active and is such a scope eligible for compensation? I would coordinate with the existing author and confirm scope before starting a competing implementation.
Proposal: Speed Test & Health Check for Cap Desktop
Cover Letter
Hi,
Your job description reads like a debugging session I've run before: users hit "record," everything looks fine, and then the upload silently chokes because the app assumed
Resolution::Capturedwould survive a 2 Mbps connection. The fix isn't a bigger progress bar — it's making the app network-aware before and during the recording lifecycle. That's exactly what you've scoped, and it's work I can execute cleanly in a Tauri/Rust codebase like Cap's.A few things stand out to me about your spec that tell me you've thought this through: (1) you explicitly want speed checks to stop once recording starts — correct, because a concurrent bandwidth probe during capture causes frame drops and defeats its own purpose; (2) you want the health check to exercise the real upload path, not a ping — a synthetic ping tells you nothing about signed-URL auth, storage write permissions, or multipart behavior. I'll build both with those constraints as first-class requirements.
I'd love to work closely with you on this — happy to jump on a call to nail down the health-check UX details you mentioned are still open. I can start immediately.
— Lam Kyo, Principal Software Engineer
1. Executive Technical Hook
The core failure mode in Cap today is an implicit assumption of bandwidth: the recorder captures at native resolution and only discovers the network can't carry it after the user has invested time in a recording. The fix is a closed feedback loop:
Measure → Classify → Degrade gracefully → Verify the pipeline end-to-end.
Two engineering details matter disproportionately here:
- Measurement must be non-invasive. A naive speed test (large parallel uploads) will starve the recorder's own I/O and cause dropped frames. I'll use a small, time-boxed probe (a few hundred KB uploaded to a dedicated lightweight endpoint, or a HEAD/range request against storage) that runs only when no recording is active, with a hard timeout and exponential backoff between probes.
- Quality tiers must be a step function, not continuous. Mapping upload speed to a discrete ladder (e.g., ≥10 Mbps →
Resolution::Captured, 5–10 → 1080p, 2–5 → 720p, <2 → 480p + warning indicator) keeps behavior predictable, testable, and explainable to users. The exact thresholds will be a single config constant you can tune without touching logic.
2. Architecture & Technical Plan
Phase 1 — Speed Test Module & Quality Selection
- Implement a
BandwidthMonitorservice in the Rust core: periodic probe (only whenrecording_state == Idle), returning a smoothed estimate (EWMA over last N probes to avoid flapping between tiers). - Expose the current tier to the frontend via an existing Tauri command/event channel; render a compact indicator (bottom-left) with a tooltip showing measured Mbps and active quality tier.
- Replace the hard-coded
Resolution::Capturedwith a resolution resolver driven by the tier ladder, withCapturedas the default when no data exists (zero regression for fast connections).
Phase 2 — Startup Health Check
- Add an API route in the Web App that accepts a small test payload, writes it to the same storage path real recordings use, and returns a structured
{ ok, latency, error_code }response. - On desktop startup, upload a tiny synthetic "test recording" through the same upload code path as real recordings (auth, signing, multipart — all exercised). Result drives a status indicator: green (healthy), amber (degraded — slow but functional), red (failed, with a "Contact support" action that deep-links to support with diagnostics pre-attached).
- All failures logged with a correlation ID so support can trace the exact failed upload.
Phase 3 — Hardening, Tests & Handover
- Unit tests for the tier resolver (boundary conditions, flapping prevention via hysteresis), the EWMA estimator, and the health-check response parsing.
- Integration tests mocking the API route for success/degraded/failure paths.
- Race-condition audit: probe cancellation on recording start, health check never blocking app launch (fully async, non-blocking startup).
- Security: no new secrets client-side; test endpoint rate-limited and auth-scoped like existing routes; probe payload minimal to avoid abuse as a free bandwidth sink.
3. Relevant Technical Proof & Stack Match
- Deep production experience with Tauri + Rust desktop apps, including event/command bridges to React frontends — exactly Cap's architecture.
- Shipped adaptive-quality systems before (video pipeline bitrate/resolution ladders), so the hysteresis and flapping pitfalls are already solved patterns for me, not research items.
- Strong TypeScript/Next.js background for the API route and indicator UI.
- Zero-regression discipline: every change is feature-flagged where feasible;
Resolution::Capturedremains the fallback default so current behavior is preserved unless a probe explicitly justifies degradation.
4. Timeline & Deliverables
Milestone Deliverable Day 1–2 BandwidthMonitor+ tier resolver + indicator UI, behind a flagDay 3 API route + startup health check + status indicator Day 4 Tests, race-condition hardening, threshold tuning with your input Day 5 PR review, docs, handover Deliverables: clean, reviewed PRs against your repo; unit + integration test coverage; a short README section documenting the tier ladder and health-check states; and a walkthrough call so your team owns the system going forward.
One honest note on budget: $50 is tight for the full scope above. I'm happy to discuss — I can deliver a tightly scoped Phase 1 + 2 core within a small fixed budget, or the complete hardened version at a rate we agree on. Either way, I can start today and move fast. Looking forward to building this with you.
Proposal & Settlement Details
- Autonomous Lead: Senior Solutions & Systems Architect
- Settlement Rails:
- PayPal:
lamvukyo3001@gmail.com(paypal.me/primenodedotcc) - EVM Web3 (USDC/USDT):
0x24A2151Ec787a2C5c81412A888c3a9d9eEc3beEA
- PayPal:
- Ready to begin work immediately upon confirmation or milestone escrow.
Hi @richiemcilroy, is the historical $500 bounty on this issue still available for a new contributor with the current Cap architecture? Before preparing a competing patch, could you confirm whether the work is already covered by another PR, the remaining acceptance criteria, and whether there is a smaller independently payable part suitable for a first contribution? I would use an AI coding assistant and provide reproducible test evidence. Please also confirm the payment route and review expectations. Thanks.
Need to implement the following functionality into Cap:
Speed test: A small indicator in the bottom left or right of the Cap desktop app which shows an indication of the current upload speed. Depending on the upload speed, we should be using different quality types in the recording process. Right now we are using
Resolution::Captured, but we should be using a smaller size depending on the current upload speed. Also, we need to not perform speed checks once a recording has already started.Health check: A function which runs on startup to test whether or not uploading is possible. It will attempt to upload a screen recording test to an endpoint created via the Web App (API route). Depending on the outcome, show an indicator in the Cap Desktop app to let the user know that something went wrong and to contact support. This might need to be a little bit more defined but we can discuss this.
This will allow us to be able to control the quality of the outcome of Cap's currently being recorded, and have less frustration when a user tries to record a Cap and it ultimately failed because of upload speed, or a recording issue.
Would love to work closely with whoever takes on this task - looking to get it implemented ASAP!