Repository navigation
Keep uploads alive on congested uplinks - #2702
heidar-droid wants to merge 1 commit into
Conversation
The connectivity probe gave cap.so 5s to answer a HEAD. While an upload saturates a slow or bufferbloated uplink (e.g. a phone hotspot), that request routinely takes longer, so uploads paused as 'network loss' and gave up after 5 minutes, leaving the cap stuck in processing and blocking new recordings. - probe timeout 5s -> 20s - network recovery window 5 min -> 30 min - max multipart chunk 15 MB -> 5 MB, so a single part fits the 5 min PUT timeout on slow links and a failed part costs less to resend Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const MIN_CHUNK_SIZE: u64 = 5 * 1024 * 1024; | ||
| const MAX_CHUNK_SIZE: u64 = 15 * 1024 * 1024; | ||
| const NETWORK_RECOVERY_TIMEOUT: Duration = Duration::from_secs(5 * 60); | ||
| const MAX_CHUNK_SIZE: u64 = 5 * 1024 * 1024; |
There was a problem hiding this comment.
Capping every part at 5 MiB lowers the largest S3 upload from about 146 GiB to 48.8 GiB. from_pending_file_to_chunks keeps increasing part_number, so larger files reach part 10,001 and S3 rejects the upload after thousands of parts have been sent. Paid users can reach this path through upload_exported_video without a size or duration cap.
Keep smaller parts for slow links, but increase their size when needed to stay within S3’s 10,000-part limit.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/desktop/src-tauri/src/upload.rs
Line: 139
Comment:
**Large exports stop uploading**
Capping every part at 5 MiB lowers the largest S3 upload from about 146 GiB to 48.8 GiB. `from_pending_file_to_chunks` keeps increasing `part_number`, so larger files reach part 10,001 and S3 rejects the upload after thousands of parts have been sent. Paid users can reach this path through `upload_exported_video` without a size or duration cap.
Keep smaller parts for slow links, but increase their size when needed to stay within S3’s 10,000-part limit.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
|
Thanks for this! Before we can review it further it needs a Greptile confidence score of 5/5. Could you address Greptile's remaining comments and push an update? Once it's at 5/5 we'll run the full CI and regression suites on it. |
This branch was previously deployed
2 participants
On a slow or bufferbloated uplink (a phone hotspot in our case), the upload itself fills the link and the connectivity probe's 5s HEAD to the web app times out. Uploads then pause as "network loss" and give up after 5 minutes. The cap stays in processing and the desktop app refuses new recordings while the upload is marked active. Logs show
Network loss detectedfollowed byNetwork recovery timeout exceeded (5 minutes), giving up, while the same HEAD answers in 0.2s once the upload stops.Changes in
upload.rs: probe timeout 5s to 20s, recovery window 5 to 30 minutes, max multipart chunk 15 MB to 5 MB so a part fits the 5-minute PUT timeout on slow links and a failed part is cheaper to resend.Fix the reduced maximum upload size before merging.
Findings
Fix with agent prompt
Summary
Gives uploads more time to survive slow or congested connections.
Reviews (1) · Last reviewed commit: "fix(desktop): keep uploads alive on cong..." · Reviewed by Greptile