Conversation
A task no longer waits for its upload to the remote cache, so tasks that depend on it start right away. Once all tasks are done, vp run waits for the uploads still running and says how many there are. Ctrl-C cancels them, and the summary warns that they weren't uploaded. Fast-fail doesn't cancel them, so tasks that succeeded before another one failed are still uploaded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Enable reqwest's http2 feature. HTTPS endpoints use HTTP/2 if the server accepts it during the TLS handshake and HTTP/1.1 otherwise. HTTP endpoints stay on HTTP/1.1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fspy benchmarklinuxmacoswindows |
prepare_upload returns the upload as an async block that owns what it needs, in place of the PendingUpload struct and its send method. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Whether an upload is still running when the tasks finish depends on how fast the remote cache responds, so the steps that upload delayed the test backend's stores to make the waiting message appear. The delay only made it likely. VP_RUN_INTERNAL_HIDE_PENDING_UPLOADS hides the message, and those steps set it instead. The backend's store delay is removed. pending_uploads uses stalled-remote-cache, where the uploads never finish, so the message always appears, and the case now runs on Windows too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
It was removed because its upload fails in the background right after it starts, so whether the message about pending uploads appeared depended on timing. With VP_RUN_INTERNAL_HIDE_PENDING_UPLOADS hiding that message, the case is stable again, and a background upload that fails with a network error is covered again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
vtt stalled-remote-cache is back to main's version, without --fetch-miss. remote-cache-server takes --stall ROUTE instead: the backend reads requests to the route but never answers them, and emits a "stalled" milestone when one arrives. The wrapper now leaves Ctrl-C to the command. pending_uploads, ctrl_c_during_upload, fast_fail_during_upload, and hide_pending_uploads use --stall /store, so like the other backend cases they need Node.js and are skipped on Windows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been 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
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.
Motivation
In
read-writemode, a task waited for its upload to the remote cache before it counted as finished, so every task that depended on it waited too. A slow remote cache slowed down the whole run, even though nothing in the run needed the upload. Once uploads run side by side, HTTP/1.1 also opens a connection for each one; HTTP/2 lets them share one.Changes
vp runprintsWaiting for N remote cache uploads to finish (Ctrl-C to cancel)...and waits for them before the summary. An upload's error is set later, through theArc<OnceLock<UploadError>>inCacheUpdateStatus::Updated, and the summary reads it after the wait.docs/cancellation.mdcovers both.http2feature is on. HTTPS endpoints use HTTP/2 if the server accepts it in the TLS handshake and HTTP/1.1 otherwise.http://endpoints stay on HTTP/1.1.VP_RUN_INTERNAL_HIDE_PENDING_UPLOADS, which keeps the waiting line out of their output, including the first step ofrestore_failurefrom fix(cache): fail the run when a cache hit's outputs can't be restored #770.remote-cache-servertakes--stall ROUTE, which reads requests to the route but never answers them, so the cases that show the waiting line or cancel uploads use--stall /store. Like the other backend cases, they need Node.js and are skipped on Windows. New e2e cases:pending_uploads,hide_pending_uploads,ctrl_c_during_upload, andfast_fail_during_upload. A unit test checks that the client offersh2over TLS.Notes for reviewers
--concurrency-limit. A large graph with a slow endpoint can pile them up. A cap is left for a follow-up.http3feature needs--cfg reqwest_unstablein every build, vite-plus included, adds aws-lc-rs next to ring, bypasses proxies, and is used only when the client forces HTTP/3 for every request.🤖 Generated with Claude Code