fix: upload_systest_dep.sh: ignore-content-length#10662
Merged
Conversation
When a systest dependency (e.g. the SEV-recovery GuestOS disk image) is
present only in bazel-remote's proxy/upstream backend and not yet in the
local disk cache, bazel-remote answers the existence HEAD probe with an
invalid 'Content-Length: -1' header (its Contains() reports the size as
unknown). curl rejects that header with exit code 8 ('Invalid
Content-Length: value') before the script can read the HTTP status code,
so the already-cached dep is misreported as an unreachable bazel-remote
and the test setup fails (observed in //rs/tests/nested:sev_recovery).
Pass --ignore-content-length to the HEAD probe so curl skips parsing the
bogus header and returns the real status code (200), correctly detecting
the dep as already uploaded.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR deflakes Farm-based systest setup by making the bazel-remote cache probe robust to invalid Content-Length headers returned on HEAD responses when artifacts exist only in the proxy/upstream backend.
Changes:
- Add
--ignore-content-lengthto thecurl --headprobe indep_in_cache()so curl still returns the HTTP status code even when bazel-remote responds withContent-Length: -1. - Document the underlying bazel-remote behavior and why the flag is required to avoid misclassifying cached artifacts as connectivity failures.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
frankdavid
approved these changes
Jul 6, 2026
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.
Problem
//rs/tests/nested:sev_recovery(and potentially any Farm-based systest) canfail during setup with what looks like a bazel-remote connectivity error:
Example run: https://github.com/dfinity/ic/actions/runs/28751952218/job/85252526147
Root cause
It is not a reachability problem.
upload_systest_dep.sh'sdep_in_cache()probes bazel-remote with a
HEADrequest and reads only the HTTP status code:code=$(curl --silent --show-error --max-time 30 -o /dev/null -w '%{http_code}' --head "$url")bazel-remote's
HEADhandler answers with, unconditionally:Contains()returns "the size if known (or -1 if unknown)". A blob found inthe local disk cache always has a real size — which is why the two
devimages just above returned
200(already uploaded). But on a local missContains()falls through to the proxy/upstream backend, which can report ablob as present but with unknown size (-1). The SEV-recovery disk image was
only in the proxy backend on that runner's cluster, so bazel-remote emitted the
literal header
Content-Length: -1.curl treats a negative Content-Length as a protocol violation and aborts with
exit code 8 (
Invalid Content-Length: value) before printing%{http_code}.The
if ! code=$(curl …)branch then fires, the script printsFailed to reach bazel-remote…and exits 1, failing the test setup. Because itdepends on whether the blob happens to be proxy-only vs. locally cached on a
given runner, the failure is intermittent.
Fix
Pass
--ignore-content-lengthto theHEADprobe. curl then skips parsing thebogus header and returns the real status code (
200), so an already-cached depis correctly detected as uploaded instead of being misreported as an unreachable
server.