[vedanth-jadhav]

S3 multipart uploads wait for each part's signed URL only after the preceding PUT finishes, adding an API round trip per part to transfer latency.

Prefetch one next-part URL while the current PUT runs. Body transfers stay strictly ordered with one PUT and one current payload buffer; chunk reads/replacement verification are unchanged. Drive URLs and Content-MD5/custom uploads keep serialized presigning. Deferred retries request a fresh URL, cancellation drops both futures, and successful PUTs report progress immediately.

Controlled measurements

Full multipart-stage transfers over real loopback HTTP using the existing WAN model, not a production WAN or whole Share/export measurement. Linux AMD EPYC 9V74 host with a two-CPU quota; Rust 1.99.1, release opt-level 3, thin LTO, one codegen unit. Five fresh processes per version and case, alternating order; 100 Mbps modeled link, 20 ms presign service, injected RTT:

Synthetic payload / RTT	Before	After
60MB /150ms	10.29158s	8.44143s
60MB /50ms	6.81693s	6.36040s
1MB /150ms	1.83016s	1.83009s
1MB /0ms	0.10467s	0.10467s

At 150 ms RTT, the median falls by 1.85 s (18.0%); observed ranges are 10.28–10.32 s before and 8.40–9.61 s after. All 40 runs preserve received bytes, ordered PUTs, completion part metadata, monotonic progress and a maximum of one active PUT. Single-part controls are unchanged. Candidate TCP connections ranged from 2–3 versus 2 on baseline; those runs are included, and exact socket reuse is not promised. Raw samples, ranges, source snapshots and reproduction.

Verification and risk

• 15 multipart tests pass in an exact-source native release harness, including 7 new byte/order/retry/cancellation/provider/fingerprint cases; the original serial transport tests pass unchanged.
• Full GPUI app and test targets pass cargo check --locked -p cap-desktop-gpui --bin cap-gpui --tests; full GUI tests were not executed.
• Scoped stable Rust formatting, workspace formatting and diff checks pass.
• Strict GPUI Clippy under Rust1.99.1 is blocked by the same 78 pre-existing diagnostics on baseline and candidate, with no new diagnostics and no suppressions.

No new dependencies, payload pre-reading or parallel PUTs; the payload-buffer count is unchanged. One speculative metadata request can be discarded on cancellation; source verification still precedes every PUT. The existing ignored multipart network benchmark now includes shared-client serial versus prefetched modes. Reproduce after normal GPUI setup with CAP_UPLOAD_BENCH_MB=60 cargo test --release --bin cap-gpui multipart_mock_network_benchmark -- --ignored --nocapture from apps/desktop-gpui.

Confidence Score: 5/5

The PR appears safe to merge; no actionable issues were found.

Summary

Prefetches the next S3 part’s signed URL while the current part uploads.

• Multipart uploads fetch the next S3 URL during the current part transfer.

No actionable issues found. This review used source inspection; no builds, tests, or benchmarks were run.

_{Reviews (1) · Last reviewed commit: "perf(gpui): prefetch signed URLs during ..." · Reviewed by Greptile}

[vercel]

Someone is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[vedanth-jadhav]

Investigated the failed GNOME screenshot check from the full job log and uploaded artifact (the CLI artifact redirect was blocked; the connected GitHub artifact download worked). The exact failed assertion is cap_alive=yes: the screenshot PNG is saved at 1920×1080, capture_failed=0, and panics=0, but profile/logs/cap-gpui.log.crashes records SIGSEGV, fault address 0x1, PID 756. The last application log entries are Vulkan/llvmpipe initialization. There is no native backtrace in this artifact, so the crash's cause is not established; I have not hidden the failure, changed unrelated code, or treated a rerun as a fix. Evidence: https://github.com/CapSoftware/Cap/actions/runs/40293878616/job/121475193327 and artifact 12637719322.