CI: Retry mysterious HTTP 413 (Too Large) Coverity uploads - #2474
Closed
eduard-bagdasaryan wants to merge 6 commits into
Closed
CI: Retry mysterious HTTP 413 (Too Large) Coverity uploads#2474eduard-bagdasaryan wants to merge 6 commits into
eduard-bagdasaryan wants to merge 6 commits into
Conversation
When the "Coverity scan" Github job uploads the results produced by cov-build to the free Coverity Scan service (scan.coverity.com) it sometimes fails because the nginx server responds with "413 Request Entity Too Large". The file generated by cov-build is < 300MB that goes below the Coverity-declared limit of 500MB (special and non-trivial configuration steps should be done for bigger files). One possible explanation is that the intermittency of the failures is caused by load-balanced routing, where a few of Coverity's upstream nginx edge instances are misconfigured or have lower size limits than 500MB. Enabling curl retry mode should probably overcome such load-balancing nginx issue (or any other sporadic network bottlenecks/delays causing this problem).
In my tests the results produced by the maximum (-9) xz level compared to the the default (-6) give ~10% better compression ratio.
This reverts commit d96e881.
kinkie
approved these changes
Aug 14, 2026
rousskov
added
M-cleared-for-merge
Contributor
|
The last failed run can still be seen at https://github.com/squid-cache/squid/actions/runs/27898377216/job/82554055617: |
squid-anubis
pushed a commit
that referenced
this pull request
Aug 16, 2026
When our coverity-scan GitHub Actions job uploads the results produced by `cov-build` to the Coverity Scan service, the upload sometimes fails with an HTTP 413 (Request Entity Too Large) error response. By default, curl does not treat HTTP 413 responses as intermittent errors and, hence, does not retry them. We speculate that those errors might be caused by Coverity misconfiguration, _and_ that Coverity may use several differently-configured servers behind some kind of load balancer, making those errors worth retrying. Besides enabling five retry attempts, this change also reports upload-related sizes in hope to provide more information if those retries fail to work around the problem: Curl already reports its notion of the upload size, but that reporting is a bit odd/obscure, so we also add a dedicated `ls` output. We also report raw/uncompressed upload size now, in case Coverity is using that to limit uploads.
squid-anubis
added
the
M-waiting-staging-checks
squid-anubis
added
M-merged
rousskov
removed
the
S-could-use-an-approval
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
4 participants
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.
When our coverity-scan GitHub Actions job uploads the results produced
by
cov-buildto the Coverity Scan service, the upload sometimes failswith an HTTP 413 (Request Entity Too Large) error response. By default,
curl does not treat HTTP 413 responses as intermittent errors and,
hence, does not retry them. We speculate that those errors might be
caused by Coverity misconfiguration, and that Coverity may use several
differently-configured servers behind some kind of load balancer, making
those errors worth retrying.
Besides enabling five retry attempts, this change also reports
upload-related sizes in hope to provide more information if those
retries fail to work around the problem: Curl already reports its notion
of the upload size, but that reporting is a bit odd/obscure, so we also
add a dedicated
lsoutput. We also report raw/uncompressed upload sizenow, in case Coverity is using that to limit uploads.