Skip to content

test(cache): number remote cache blobs and corrupt them through the backend - #808

Merged
wan9chi merged 1 commit into
remote-cache-e2e-lifetimefrom
remote-cache-e2e-blobs
Nov 7, 2026
Merged

wan9chi merged 1 commit into
remote-cache-e2e-lifetimefrom
remote-cache-e2e-blobs

Conversation

@wan9chi

@wan9chi wan9chi commented Oct 5, 2026 •

Copy link
Copy Markdown
Member

Motivation

Cases referred to blobs through the file backend's storage. Its blob IDs were sequential, and corrupt_archive overwrote remote-cache/blobs/1 directly. Vite+'s Cloudflare remote cache stores blobs in R2 under random IDs, so those cases couldn't run against it.

Changes

  • The tap numbers blobs in upload order in the request lines, e.g. GET /blob/1 200.
  • remote-cache-server corrupt-blob NUMBER overwrites a stored blob through the backend. corrupt_archive uses it.
  • The file backend uses random UUIDs as blob IDs, as the Worker does, so the numbering is already exercised here.

The only snapshot change is corrupt_archive's command line.

Stacked on #807.

🤖 Generated with Claude Code


Note

Low Risk
Changes are limited to Node test/daemon tooling and snapshot fixtures, not production vt cache client behavior.

Overview
Remote cache test tooling now matches production-style random UUID blob IDs instead of sequential numeric files, while keeping E2E snapshot logs stable by numbering blobs by upload order in tap output (e.g. GET /blob/1).

A new remote-cache-server corrupt-blob NUMBER command overwrites the nth stored blob through the backend control API; the corrupt_archive snapshot switches from direct vtt write-file on remote-cache/blobs/1 to this command. Docs and state.json drop next_blob_id; the backend exposes writeBlob for corruption from the daemon.

Reviewed by Cursor Bugbot for commit 1a7799e. Bugbot is set up for automated code reviews on this repo. Configure here.

@github-actions

github-actions Bot commented Oct 5, 2026 •

Copy link
Copy Markdown

fspy benchmark

linux

dynamic/launch             change  +1.14%  [ -6.85% .. +10.04%]  overhead   +63.01%
dynamic/access             change  +0.76%  [ -5.33% .. +14.71%]  overhead   +22.99%
dynamic/access-relative    change  -0.60%  [-15.87% ..  +6.74%]  overhead   +68.69%
dynamic/access-contended   change  -1.62%  [-12.69% ..  +7.81%]  overhead    +2.87%
static/launch              change  -0.21%  [ -6.51% ..  +7.13%]  overhead  +199.03%
static/access              change  +0.80%  [-13.33% .. +13.13%]  overhead +1465.75%
static/access-relative     change  +1.92%  [-17.26% .. +22.81%]  overhead +1398.49%
static/access-contended    change  -1.39%  [-12.23% ..  +4.14%]  overhead +1096.40%

macos

dynamic/launch             change  +1.46%  [ -4.84% ..  +5.86%]  overhead  +256.44%
dynamic/access             change  +0.25%  [-15.23% ..  +8.08%]  overhead    +0.00%
dynamic/access-relative    change  -0.97%  [-50.07% ..  +5.98%]  overhead  +246.95%
dynamic/access-contended   change  +1.09%  [ -5.40% .. +10.71%]  overhead    +3.95%

windows

dynamic/launch             change  +0.00%  [ -1.12% ..  +1.20%]  overhead   +26.05%
dynamic/access             change  +0.00%  [ -0.57% ..  +0.59%]  overhead    +1.16%
dynamic/access-relative    change  +0.19%  [ -0.55% ..  +0.76%]  overhead    +1.16%
dynamic/access-contended   change  +0.00%  [ -0.69% ..  +0.72%]  overhead    +1.50%

@wan9chi
wan9chi added this pull request to stack #812 October 5, 2026 05:59
@wan9chi
wan9chi removed this pull request from stack #812 October 6, 2026 02:42
@wan9chi
wan9chi added this pull request to stack #813 October 6, 2026 02:42
@wan9chi
wan9chi force-pushed the remote-cache-e2e-blobs branch from 25cb732 to aa77591 Compare October 6, 2026 02:48
@wan9chi wan9chi added the remote cache Remote caching label Nov 4, 2026
…ackend

Cases referred to blobs through the test backend's storage: its blob IDs
were sequential, and `corrupt_archive` overwrote `remote-cache/blobs/1`
directly. A backend that stores blobs differently, such as the public
cache service with its random blob IDs, couldn't run those cases.

The tap now numbers blobs in upload order in the request lines, and
`remote-cache-server corrupt-blob NUMBER` overwrites a stored blob
through the backend. The test backend uses random UUIDs as blob IDs,
like the service. The only snapshot change is `corrupt_archive`'s
command line.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@wan9chi
wan9chi force-pushed the remote-cache-e2e-blobs branch from aa77591 to 1a7799e Compare November 7, 2026 10:01
@wan9chi
wan9chi removed this pull request from stack #813 November 7, 2026 10:41
@wan9chi
wan9chi added this pull request to stack #958 November 7, 2026 10:42
@wan9chi
wan9chi marked this pull request as ready for review November 7, 2026 11:02
@wan9chi
wan9chi merged commit c3ed6aa into main Nov 7, 2026
23 checks passed
@wan9chi
wan9chi deleted the remote-cache-e2e-blobs branch November 7, 2026 11:15
wan9chi added a commit that referenced this pull request Nov 7, 2026
…ons stand-in (#809)

## Motivation

[Vite+'s Cloudflare remote
cache](https://github.com/voidzero-dev/vite-plus-remote-cache-cloudflare)
only accepts uploads with a GitHub Actions OIDC token. The token has to
come from a push to the registered repository's main branch, and its
audience has to be the endpoint. The file backend accepted any upload,
so the e2e cases never sent a token and never exercised the client's
OIDC support from #798.

## Changes

- **GitHub Actions stand-in.** The backend process stands in for
GitHub's token service. `remote-cache-server run --github-actions` runs
a command as if in a job with `id-token: write`: it sets
`ACTIONS_ID_TOKEN_REQUEST_URL`, and `ACTIONS_ID_TOKEN_REQUEST_TOKEN`
defaults to `main-push`. The request token picks the workflow run the
token is for: `main-push` or `pull-request`.
- **Write policy.** Like the Worker, the file backend checks each
store's token: its RS256 signature against the stand-in's key, its time
bounds, its audience, and its claims. It answers other stores as the
Worker does, with `401 Invalid credentials` or `403 Write not
permitted`.
- **Uploading steps** run with `--github-actions`. The only snapshot
changes are those command lines.

Stacked on #808.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Changes are limited to test tooling (`remote-cache-server`) and e2e
fixtures; production cache client code is only invoked more
realistically in tests.
> 
> **Overview**
> Aligns the **remote-cache test backend** with production by requiring
a **GitHub Actions OIDC token** on `POST /store` (401/403 otherwise),
while **fetch/read stays unauthenticated**.
> 
> A new **`--github-actions`** flag on `remote-cache-server run`
simulates a job with `id-token: write` (`ACTIONS_ID_TOKEN_REQUEST_URL` /
default `main-push` request token). The daemon’s control server exposes
a **`/token`** endpoint that mints RS256 JWTs; **`backend.ts`** verifies
signature, time bounds, audience (endpoint), and push-to-`main` claims
before accepting stores. E2E **upload steps** and snapshot command lines
now pass **`--github-actions`** so tests exercise the client OIDC path.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
a31b6bf. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

remote cache Remote caching

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant