Summary
When vp run fails to encode a task's cache key, it prints the failure to stdout, then runs zero tasks and exits 0.
$ vp run codegen
✗ Cache lookup failed: Encoded sequence length exceeded preallocation limit of 4194304 bytes (needed 9831192 bytes)
---
vp run: 0/0 cache hit (0%). (Run `vp run --last-details` for full details)
$ echo $?
0
The task never executed, nothing was generated, and the exit status says everything is fine.
Impact
This reached us through a CI check that regenerates a committed artifact and diffs it. The check ran vp run <codegen task>, got exit 0, compared the file against itself, and reported "up to date" — while codegen had not run at all. The check had been structurally incapable of noticing.
In CI (Linux) the same invocation exited with status 135 instead of 0, with no output at all, which is a second inconsistency: the same condition produces a silent success locally and an unexplained non-zero status in CI.
Expected
A cache-layer failure should never be able to skip work. Either fall back to running the task uncached, or fail loudly with a non-zero exit. 0/0 tasks executed with exit 0 should not be reachable when a task was requested.
Two smaller points:
- The diagnostic goes to stdout, so it disappears for any caller using
stdio: ["ignore", "ignore", "inherit"] — which is a natural choice for a wrapper that only cares about stderr. It belongs on stderr.
- 4 MiB looks like a fixed preallocation rather than a limit that should be enforced; growing past it is a normal thing for a large workspace to do.
Reproduction
I do not have a minimal reproduction — the encoded size depends on workspace scale. Ours crossed the threshold at roughly 1,300 first-party source files after an import-graph change; the task itself is a single graphql-codegen invocation whose output is ~870 KB. Scaling a synthetic workspace to 80,000 trivial modules did not reach the limit, so the encoded sequence appears to be driven by something other than raw input file count.
Happy to gather more detail if there is a debug flag that dumps what goes into the cache key.
Environment
vp 0.1.24- Local: macOS 15 (Darwin 25.4.0), arm64, Node 26.8.1 → exit 0,
0/0
- CI: Linux x86_64, Node 26.8.1 → exit 135, no output
Possibly related to #2635 (cache layer degrading to a silent success).
Summary
When
vp runfails to encode a task's cache key, it prints the failure to stdout, then runs zero tasks and exits 0.The task never executed, nothing was generated, and the exit status says everything is fine.
Impact
This reached us through a CI check that regenerates a committed artifact and diffs it. The check ran
vp run <codegen task>, got exit 0, compared the file against itself, and reported "up to date" — while codegen had not run at all. The check had been structurally incapable of noticing.In CI (Linux) the same invocation exited with status 135 instead of 0, with no output at all, which is a second inconsistency: the same condition produces a silent success locally and an unexplained non-zero status in CI.
Expected
A cache-layer failure should never be able to skip work. Either fall back to running the task uncached, or fail loudly with a non-zero exit.
0/0tasks executed with exit 0 should not be reachable when a task was requested.Two smaller points:
stdio: ["ignore", "ignore", "inherit"]— which is a natural choice for a wrapper that only cares about stderr. It belongs on stderr.Reproduction
I do not have a minimal reproduction — the encoded size depends on workspace scale. Ours crossed the threshold at roughly 1,300 first-party source files after an import-graph change; the task itself is a single
graphql-codegeninvocation whose output is ~870 KB. Scaling a synthetic workspace to 80,000 trivial modules did not reach the limit, so the encoded sequence appears to be driven by something other than raw input file count.Happy to gather more detail if there is a debug flag that dumps what goes into the cache key.
Environment
vp0.1.240/0Possibly related to #2635 (cache layer degrading to a silent success).