Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
fspy benchmarklinuxmacoswindows |
Remote cache stagingCommit: Cloudflare deployment or e2e verification failed. The staging deployment is not marked ready. See the workflow run. |
fengmk2
force-pushed
the
feat/public-remote-cache
branch
from
September 14, 2026 15:16
194d39f to
e461d47
Compare
Member
Author
|
Deploy prompt:
|
wan9chi
force-pushed
the
feat/public-remote-cache
branch
from
September 27, 2026 16:04
df2d129 to
e127e9b
Compare
wan9chi
added this pull request to stack #759
September 27, 2026 16:04
wan9chi
force-pushed
the
feat/public-remote-cache
branch
from
September 27, 2026 16:32
e127e9b to
d4b0fea
Compare
wan9chi
force-pushed
the
feat/public-remote-cache
branch
from
September 27, 2026 17:15
58347c9 to
c2f00bd
Compare
wan9chi
removed this pull request from stack #759
September 27, 2026 17:15
wan9chi
added this pull request to stack #773
September 27, 2026 17:16
wan9chi
added a commit
that referenced
this pull request
Sep 28, 2026
## Motivation The public cache service (#718) follows its RFC and answers a fetch that matches neither key with HTTP 404 and a plain-text body. It never sends `kind: "not_found"`. The client and the Node test backend still used a 200 response with `kind: "not_found"`, so a miss meant different things depending on the server. This switches both to 404 and drops the `not_found` kind, giving the client and both servers one miss contract. ## Changes - `vt_remote_cache`: `Client::fetch` returns `Result<Option<Fetched>, Error>`, with `None` for a 404 response. `Fetched` only describes the body of a 200 response, so its `NotFound` variant is removed. A 200 response with `kind: "not_found"` is now a malformed response. Every other non-200 status is still an error, and a 404 download still fails. - Test backend (`packages/tools`): a fetch miss gets a 404 with the body `Not found`, logged as `POST /fetch 404`. - The remote cache e2e snapshots change only in those backend lines and responses. The `vp run` output is unchanged. --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Remove the obsolete cache size study and its RFC link. Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
Co-authored-by: GPT-6 Codex <codex@openai.com>
`npm_execpath` points to pnpm's standalone executable on the Linux and Windows runners, so running it through `node` failed. Run it directly unless it's a JavaScript entry point. The remote cache package also brought esbuild and workerd into the workspace, and a root `pnpm install` without `--ignore-scripts` failed on their unapproved build scripts. Allow them, as the standalone package already does. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…service `remote-cache-server` now runs the Worker from `packages/remote-cache` in workerd through Miniflare instead of the Node test backend, so the e2e tests exercise `vp run` against the real service. The wrapper proxies requests to the service. It signs an upload token for each store with a key the service fetches in place of GitHub's. It numbers the service's random blob IDs in upload order for the request log, and copies each blob to `remote-cache/blobs/<number>`, storing a changed copy on the next run so tests can still corrupt an archive. The only snapshot change is the request log for a fetch miss, which the service answers with a 404. The cases are skipped on musl because workerd's prebuilt binaries require glibc. The `remote_cache_backend` fixture only tested the old backend, and the service has its own protocol tests, so it's removed along with `cbor-http` and its EDN formatting. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
wan9chi
force-pushed
the
feat/public-remote-cache
branch
from
September 28, 2026 02:52
c2f00bd to
0c55376
Compare
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.


Add
packages/remote-cachefor the server in #716, using Cloudflare Workers, primary D1 metadata, and a private R2 bucket. The server supports public reads and GitHub Actions OpenID Connect checks for writes. Stores use streaming uploads, atomic publication, storage limits, and automatic data expiry.One workflow deploys related changes to a persistent staging Worker, D1 database, and R2 bucket. Internal PRs,
mainpushes, and manual runs share these resources. The workflow runs deployments and smoke tests in sequence, then updates PR comments with the tested revision and manual instructions. Each deployment replaces the previous revision. Closing a PR keeps staging available. Setup uses repository secrets and variables. Repository maintainers can configure staging without a GitHub environment.The e2e plan defines automated checks and manual exercises. PR runs check public reads and rejected writes. Pushes to
mainalso check authorized uploads, multipart storage, replacement, concurrency, and quotas. Local tests repeat smoke checks against reused storage and retain maximum-payload and scheduled-handler coverage. Real Cron execution and maximum payloads on Cloudflare require separate release exercises./fetchreturns only{ kind: "fallback", key }for fallback matches and does not read R2. Exact matches return the value andblob_id. A missing or unreadable exact value returns503. Fetch misses and unavailable blobs return plain-text404, as specified in the local RFC.Setup rejects incompatible origins and repositories before it changes existing policies or saved configuration. Each Worker has separate rate-limit counters that remain stable across revisions. Workers Free CPU support remains unverified. The guide recommends Workers Paid for the full payload limits.
Motivation
Maintainers need a cache service in their own Cloudflare account. Developers and fork contributors must reuse public task results without login. Only trusted jobs on
mainshould publish those results. Reviewers need one persistent staging environment and a clear verification result after each related change.