Repository navigation
Keep uploads alive on congested uplinks - #2702
Open
heidar-droid wants to merge 1 commit into
Open
heidar-droid wants to merge 1 commit into
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>
Contributor
|
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; |
Contributor
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.This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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