You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 90d256f
Browse filesBrowse the repository at this point in the historyBrowse files
test(cache): make stalled-remote-cache a proxy for the remote cache (#795)
## Motivation
The e2e cases for a remote cache that never answers need some requests
to stall while others behave normally. For example, an upload case needs
its fetch to reach a backend and miss before the upload stalls. `vtt
stalled-remote-cache` was its own endpoint and stalled every request, so
it couldn't do that. #718 will replace `remote-cache-server` with the
real cache service, which can't stall requests itself. So the stalling
has to happen in front of whatever backend a test runs.
## Changes
- **Proxy.** `vtt stalled-remote-cache [--stall ROUTE]... COMMAND
[ARGS...]` is now a proxy for the endpoint in `VP_REMOTE_CACHE_URL`,
which must be `http://<host>:<port>/<path>`. It runs the command with
`VP_REMOTE_CACHE_URL` set to the proxy.
- A request to a stalled route below the endpoint, such as `/store`, is
never answered, and it emits a `stalled` milestone.
- Other requests are forwarded with `connection: close`, so each one
comes in on its own connection and is checked on its own.
- A forwarded request gets a 502 if the endpoint can't be reached.
- **Fetch cases.** `ctrl_c_during_fetch` and `fast_fail_during_fetch`
stall `/fetch`, with an unreachable endpoint behind the proxy. They
still run on every platform without Node.js.
- **New `ctrl_c_during_upload` case.** It runs `remote-cache-server vtt
stalled-remote-cache --stall /store vt run build`. The fetch reaches the
backend and misses, the upload stalls, and Ctrl-C cancels it.
- **`remote-cache-server`** now ignores Ctrl-C and leaves it to its
command, so it still prints its request log afterwards.
## Notes for reviewers
- **Lost milestones on Windows.** A milestone there is the console
title, and ConPTY sends it on its next render. If the command sets a
milestone at about the same time as the proxy, the earlier one can be
lost. The doc comment says so. Cases that need `remote-cache-server` are
skipped on Windows anyway.
- **Conflict with #718.** #718 rewrites
`packages/tools/src/remote-cache/cli.ts`, so the line that ignores
Ctrl-C needs to move into its version.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
remote-cache-server cbor-http POST /fetch --cbor "{\"key\": 'A', \"secondary_key\": 'S'}"
10
10
```
11
11
12
-
`remote-cache-server COMMAND [ARGS...]` starts the backend on a free loopback port and runs the command with `VP_REMOTE_CACHE_URL` set to the endpoint, `http://127.0.0.1:<port>/projects/test`. The fixed base path gives every endpoint a namespace path. The wrapper takes no options and passes all arguments to the command unchanged. The command inherits stdio. When it exits, the server stops and the wrapper exits with the command's exit code.
12
+
`remote-cache-server COMMAND [ARGS...]` starts the backend on a free loopback port and runs the command with `VP_REMOTE_CACHE_URL` set to the endpoint, `http://127.0.0.1:<port>/projects/test`. The fixed base path gives every endpoint a namespace path. The wrapper takes no options and passes all arguments to the command unchanged. The command inherits stdio and handles Ctrl-C, which the wrapper ignores. When it exits, the server stops and the wrapper exits with the command's exit code.
13
13
14
14
After the command exits, the wrapper prints one line to stderr for each request it served, in the order of the responses. Each line has the method, the path below the base path, and the status. Successful fetch responses add their kind:
0 commit comments