Repository navigation
Implement speed test and health check for Cap desktop app #73
Description
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!
Activity
[-]Implement speed test and health check for Cap app[/-][+]Implement speed test and health check for Cap desktop app[/+]richiemcilroy commentedon Aug 12, 2024
/bounty $500
varshith257 commentedon Aug 12, 2024
/attempt #73
varshith257 commentedon Aug 12, 2024
@richiemcilroy Could I get this assigned? I would like to work on this and complete this ASAP
onyedikachi-david commentedon Aug 12, 2024
/attempt #73
amochuko commentedon Aug 13, 2024
/attempt #73
Options
algora-pbc commentedon Aug 16, 2024
💡 @webbdays submitted a pull request that claims the bounty. You can visit your bounty board to reward.
richiemcilroy commentedon Oct 4, 2024
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).
feat: add speed test and health check system for desktop app
JYZ-LESLIE commentedon May 16, 2026
/attempt #73
Focused implementation plan (Tauri v2 + SolidJS architecture):
I will ship this in scoped increments so it is reviewable and easy to extend.
JYZ-LESLIE commentedon May 16, 2026
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.
JYZ-LESLIE commentedon May 16, 2026
/claim #73\n\nPR: #1827
evelynxuu1103-spec commentedon Jul 4, 2026
/attempt #73
FloatingPegasus commentedon Sep 7, 2026
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.
stffinfcti commentedon Sep 20, 2026
/attempt #73
furuchanchan commentedon Sep 21, 2026
@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.
calinrus-dev commentedon Oct 6, 2026
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.
ryder777777 commentedon Oct 21, 2026
/attempt #73
feat(desktop-gpui): add upload health indicator and adaptive instant …
pythonyx135793 commentedon Oct 24, 2026
Hi @richiemcilroy, is the $500 bounty still available for the current GPUI app? I noticed the bounty label was removed. I'd like to confirm that before setting up recording and upload tests or adding another competing PR.
khoap1220-hue commentedon Oct 25, 2026
/attempt #73
duongynhi000005-oss commentedon Nov 1, 2026
/claim #73
Opened PR #3630 implementing the background upload speed probe (/api/desktop/upload-health), adaptive Instant Mode resolution capping (720p / 1080p / 1440p / 4K), and the Settings UI notice + Re-test action.
feat(desktop): add upload speed health check and adaptive instant mod…
feat(desktop-gpui): implement upload speed test and network health ch…
feat(desktop-gpui): implement upload speed test and network health ch…