feat(cache): resolve remote cache configuration - #727
Merged
Merged
Conversation
wan9chi
force-pushed
the
remote-cache-config
branch
from
September 17, 2026 05:57
7855149 to
e96231c
Compare
fspy benchmarklinuxmacoswindows |
wan9chi
force-pushed
the
remote-cache-config
branch
from
September 21, 2026 10:45
e96231c to
67e02e8
Compare
wan9chi
added this pull request to stack #741
September 21, 2026 10:45
wan9chi
force-pushed
the
remote-cache-config
branch
3 times, most recently
from
September 22, 2026 14:03
65b48e0 to
e455c62
Compare
wan9chi
removed this pull request from stack #741
September 22, 2026 14:05
wan9chi
added this pull request to stack #745
September 22, 2026 14:05
wan9chi
force-pushed
the
remote-cache-config
branch
from
September 22, 2026 14:10
e455c62 to
a631878
Compare
wan9chi
force-pushed
the
remote-cache-config
branch
from
September 22, 2026 14:19
a631878 to
96e4492
Compare
wan9chi
force-pushed
the
remote-cache-config
branch
5 times, most recently
from
September 22, 2026 15:29
21cd645 to
adbd1b9
Compare
wan9chi
removed this pull request from stack #745
September 22, 2026 15:31
wan9chi
changed the base branch from
main
to
fix/windows-env-name-comparison
September 22, 2026 15:38
wan9chi
added this pull request to stack #748
September 22, 2026 15:38
wan9chi
force-pushed
the
remote-cache-config
branch
from
September 22, 2026 15:40
adbd1b9 to
4256d4a
Compare
wan9chi
force-pushed
the
remote-cache-config
branch
from
September 23, 2026 06:56
4256d4a to
a30cc6e
Compare
wan9chi
removed this pull request from stack #748
September 23, 2026 06:58
wan9chi
changed the base branch from
fix/windows-env-name-comparison
to
main
September 23, 2026 06:58
wan9chi
force-pushed
the
remote-cache-config
branch
from
September 23, 2026 11:52
a30cc6e to
c408288
Compare
wan9chi
added this pull request to stack #751
September 23, 2026 11:52
wan9chi
force-pushed
the
remote-cache-config
branch
3 times, most recently
from
September 24, 2026 09:11
03e11af to
9218032
Compare
Co-authored-by: GPT-6 <codex@openai.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: GPT-6 <codex@openai.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Carry the endpoint from `remoteCache.url` or `VP_REMOTE_CACHE_URL` as a string, so an endpoint can't fail planning before remote caching uses it. Treat empty control values as unset, as a CI secret unavailable to the job expands to an empty string. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
`VP_REMOTE_CACHE` and `VP_REMOTE_CACHE_URL` reach task processes like other `VP_*` variables, including the mode set by `--remote-cache`, so `vp` processes started by a task inherit the invocation's remote cache settings. They stay out of cache fingerprints, including envs matched by `cache.env`, command prefix envs, and runner-aware env queries, so runs with different remote access share cache entries. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Configure the workspace endpoint as `cache: { remote: { url } }` in the
workspace root config, next to the task-level `cache: { remote }` setting.
`cache` is already limited to the workspace root, so the separate
`remoteCache` check is no longer needed.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
`VP_REMOTE_CACHE` and `VP_REMOTE_CACHE_URL` now match env names by the platform's rules, so on Windows a differently spelled control selects the remote cache and stays out of fingerprints. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Resolve the `cache.remote.url` endpoint into `ResolvedGlobalCacheConfig` with the other workspace cache settings, instead of keeping it in a separate field on the task graph. `--cache` and `--no-cache` keep the configured endpoint. Store endpoints as `Arc<str>`: they are usually too long for an inline `Str`, and each cacheable execution carries a copy. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
- Report invalid remote cache envs as plan errors, like `VP_RUN_CONCURRENCY_LIMIT`, instead of through a separate error type. - Keep the invocation's remote cache config in `PlanContext` next to the resolved global cache config, instead of passing it through task planning. - Serve runner-aware env queries the same envs as before remote caching, without copying the env map for each spawn to hide the controls. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Leave each package's loaded config intact. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…evels Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
`VP_REMOTE_CACHE` and `VP_REMOTE_CACHE_URL` follow the task's `env` and `untrackedEnv` settings, and command prefixes, like any other variable. By default they pass through untracked with other `VP_*` variables, so runs with different remote access still share cache entries. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
- `PlanOptions.remote_cache_mode`: the `--remote-cache` flag. - `ResolvedRemoteCacheConfig` with `access`: resolved for a `vp run` level. - `PlanContext::resolved_remote_cache`: the level's resolved value. - `CacheConfig.remote_cache_allowed`: the task's `cache.remote`. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
wan9chi
force-pushed
the
remote-cache-config
branch
from
September 25, 2026 01:56
02bab8e to
c2aa084
Compare
wan9chi
marked this pull request as ready for review
September 25, 2026 01:56
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
wan9chi
added a commit
that referenced
this pull request
Sep 27, 2026
## Motivation #727 resolves a remote cache endpoint and access mode for each execution, but nothing uses them yet. This is the first client PR for the server API in #713: in `read-write` mode, `vp run` uploads each successful, cacheable new execution after recording it locally, so the following PRs can restore it elsewhere. The new `vt_remote_cache` crate implements `POST {endpoint}/store` over opaque bytes. It appends `/store` to the endpoint's path, keeping any namespace path, and sends a CBOR `metadata` part with the key, secondary key, and value, plus the output archive streamed as the `blob` part. Only HTTP 200 counts as success, and the response isn't decoded. The client uses reqwest with rustls and the ring provider, verifies HTTPS certificates with the operating system's verifier, and sets 10-second connect and 60-second read timeouts. `ExecutionCache` creates one client per endpoint on first use, and uploads after a successful local update, awaiting the upload inline. Hits never upload. The key is a header plus wincode(`CacheEntryKey`), the secondary key is the header plus wincode(`ExecutionCacheKey`), and the value is wincode(`CacheEntryValue`). The header contains the cache schema version and the target OS and architecture. An invalid endpoint or a failed upload never fails the task or changes the exit status. The run summary shows a warning instead, even when a single task ran, such as `vp run: build not uploaded to the remote cache: network error.` The reason names only the kind of failure, such as an invalid endpoint, a network error, or an HTTP status, so it's the same on every platform. `--last-details` adds the underlying details for each task, such as the connection error behind a network error, the parse error for an endpoint that isn't a URL, or the message in an error response's body. After the wrapped command exits, `remote-cache-server` prints one line for each request it served, such as `[remote-cache] POST /store 200` or `[remote-cache] POST /fetch 200 not_found`. The `remote_cache_backend` snapshots gain these lines. A new ignored `remote_cache` fixture shows that a `read-write` run sends one store request, a rerun is a local hit with no requests, and a `read` run after an input change reruns the task without requests. Cases in the default suite cover an invalid endpoint and port 0, where nothing can listen, on every platform. --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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
Each planned execution needs a resolved remote cache endpoint and access mode, so execution can read from or upload to the remote cache without working out the settings itself. Resolving them during planning also makes them visible in plan snapshots.
Summary
cache: { remote: { url } }sets the endpoint. A task opts out withcache: { remote: false }.--remote-cache=off|read|read-writeandVP_REMOTE_CACHEselect access, and the flag overrides the env.VP_REMOTE_CACHE_URLoverrides the configured endpoint. Without either, access isreadwhen an endpoint is configured andoffotherwise. Empty values count as unset.vp runlevel resolves its own settings from the envs it sees. A level's--remote-cachereaches nestedvp runthroughVP_REMOTE_CACHE, and a prefix such asVP_REMOTE_CACHE=off vp run buildapplies only to that command.envanduntrackedEnvlike other variables. By default they pass through untracked with otherVP_*variables, so runs with different remote access share cache entries.