Repository navigation
Conversation
Raise the zccache floor from 1.15.6 to 1.15.8, the latest PyPI/crates.io release. 1.15.8 is the version Windows CI already resolves and the version that emits the cold-start "retrying via ephemeral session" warning, so this does not silence that warning: the related Windows daemon-pipe failure class is still open upstream (forge-ci/zccache#1976). Keeping the floor at 1.15.8 stops any environment from resolving back to 1.15.6, the release named in that report, and picks up 1.15.7's same-size-edit stale-hit fix plus 1.15.8's Windows destination-delivery retry.
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Release notes and version requirement pyproject.toml |
The release notes describe zccache fixes in versions 1.15.7 and 1.15.8, and note that the Windows daemon-pipe warning remains unresolved. The minimum dependency version changes to 1.15.8. |
Priority:
Estimated code review effort: 2 (Simple) | ~8 minutes
Change: Other
Possibly related issues
- FastLED/FastLED issue 3129: The dependency update and release notes cover zccache version behavior included in the broader audit.
- FastLED/fbuild issue 1757: The minimum version update prevents resolution to 1.15.6 and includes notes about a Windows destination-delivery retry, but the change does not establish that it resolves the reported intermittent cache misses.
Merge Risk: 
Minimal · up to 4a571
-
This only raises the minimum allowed zccache version to 1.15.8, which matches what CI already resolves. The Windows daemon-pipe warning is documented as still unresolved and is not made worse by this change. No merge-blocking risk was found.
Pre-merge checks: 
5
-
Full details: Title check
-
Explanation
The title "chore(deps): require zccache>=1.15.8" matches the sole functional change in the changeset: the minimum zccache dependency floor in pyproject.toml is raised from 1.15.6 to 1.15.8. It is specific, concise, and follows conventional commit style. It does not mention the unresolved Windows daemon-pipe warning, but the PR objectives state that this PR does not address that issue, so omitting it is appropriate.
Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
Symptom
The Windows
unit tests windowsjob logs this while building the FastLED engine in debug mode (run 40472340544; ~10 occurrences, six of them in the first parallel compile burst of the engine build, then one per later test target):Every occurrence is followed by a successful compile and the job passes; there is no
FAILED/refusing to run uncachedfallout in this run.What the pin was
pyproject.toml:zccache>=1.15.6pyproject.toml:fbuild>=2.5.45./install→uv syncwith no committeduv.lock, so it resolvedfbuild==2.5.47andzccache==1.15.8(the meson marker recordedzccache 1.15.8, and that is the version in the pipe name). Thev1.15.8in the warning is the resolved version, not a hard pin.What it now is
zccache>=1.15.8— the only change in this PR.Why 1.15.8, and what this does not fix
ZCCACHE_SESSION_IDset, the wrapper's compile path connects before ensuring a daemon and, on a failed connect, prints this line and retries throughcmd_compile_ephemeral(crates/zccache-cli-core/src/cli/commands/wrap/ipc.rsin forge-ci/zccache). The ephemeral retry succeeds.The meson functional minimum stays at 1.15.6 (
ci/meson/meson_setup_execute.py), because that is the PCH-snapshot feature requirement; only the dependency floor moves.fbuild's floor is unchanged: current fbuild (2.5.47) already embeds zccache 1.15.8, and raising thefbuildfloor would not affect the venv zccache binary that the native build wraps.Reproduced / not reproduced
Reproduced on this Linux machine with the new pin:
uv syncmoved the venv from zccache 1.15.6 to 1.15.8 (zccache --version→zccache 1.15.8).ZCCACHE_CACHE_DIR, ranzccache session-start, killed the isolated daemon, then ranZCCACHE_SESSION_ID=... zccache gcc -c .... It emittedzccache[warn][S]: cannot connect to daemon at /tmp/.../daemon-v1.15.8.sock: ... Connection refused (os error 111); retrying via ephemeral sessionand still exited 0 with the object produced. This is the same client fallback as the Windows message; the Windows named pipe and its
os error 2could not be reproduced here.Not reproduced: the Windows named pipe itself, the GitHub runner's daemon disappearing between
session-startand the first parallel compiles, and any daemon/pipe fix.Validation
uv sync→zccache==1.15.8bash lint→ exit 0bash compile wasm --examples Blink→ exit 0bash test --cppdeliberately not run; the orchestrator runs it once at the end.Summary by CodeRabbit