Repository navigation
Update to Envoy Commit c661827 - #1627
Conversation
…test assertion Signed-off-by: fei-deng <101672975+fei-deng@users.noreply.github.com>
fei-deng
changed the title
- Change strict counter len assertions to assertGreaterEqual to handle Envoy http2 metrics - Add NO_REQUEST_LINE_IN_REQUEST protocol error to test server warn/error ignore list - Add 1-request tolerance for timing jitter in test_http_request_release_timing Signed-off-by: fei-deng <101672975+fei-deng@users.noreply.github.com>
Signed-off-by: fei-deng <101672975+fei-deng@users.noreply.github.com>
Signed-off-by: fei-deng <101672975+fei-deng@users.noreply.github.com>
| # the GreaterEqual matchers below. | ||
| total_requests = qps_parameterization_fixture * concurrency * math.floor(actual_duration) | ||
| # the GreaterEqual matchers below. Allow a 1-request tolerance for timing jitter. | ||
| total_requests = max( |
There was a problem hiding this comment.
Can you provide more data around this. I'd like more information to properly audit this claim.
If there is jitter, why would it be restricted to a single request? Couldn't it be for every worker before it fully completes? Do you mind explain the series of events that would lead to this edge scenario?
There was a problem hiding this comment.
-
Floored Duration Baseline: The test measures
actual_durationas a float and takesmath.floor(actual_duration)(e.g.5.002s ->5s). This flooring already establishes a conservative lower bound for expected request generation. In the CI failure logs that prompted this change, the recorded request count was off by exactly 1 request (e.g., 249 recorded vs. 250 expected). -
Mid-Run Execution: During the run, thread scheduling jitter under heavy CI load does not drop requests—Nighthawk simply executes them a few milliseconds later, and their completed responses are recorded normally in the histogram.
-
Shutdown Boundary: The only point where a request can be clipped from the recorded count is at the exact process termination cutoff, where 1 in-flight request may be incomplete when statistics capture stops.
Subtracting 1 request (- 1) provides a simple, effective global floor tolerance for boundary timing jitter under CI load, ensuring the integration test runs reliably without flaking.
There was a problem hiding this comment.
Ack. Since we've only observed -1, I think we can keep this test expectation but I think theoretically each worker acts independently and cause a flake although that would be extremely rare.
Signed-off-by: fei-deng <101672975+fei-deng@users.noreply.github.com>
Signed-off-by: fei-deng <101672975+fei-deng@users.noreply.github.com>
0eb2129 to
ac6885d
Compare
|
Can you update the PR description to match the current implementation? Then I'll merge it. |
Signed-off-by: fei-deng <101672975+fei-deng@users.noreply.github.com>
When envoyproxy#1627 synced .bazelrc with upstream Envoy PR envoyproxy/envoy#47806, it removed try-import %workspace%/repo.bazelrc from the bottom of .bazelrc. However, .github/workflows/_ci.yml still writes the CI compiler and resource configurations to repo.bazelrc, so Bazel no longer loads those settings during CI runs. This PR replaces repo.bazelrc with user.bazelrc in .github/workflows/_ci.yml (and adds the upstream Envoy fallback in ci/do_ci.sh to copy repo.bazelrc to user.bazelrc if present), as user.bazelrc remains imported at the bottom of .bazelrc and ignored by .gitignore. Signed-off-by: tomjzzhang <4367421+tomjzzhang@users.noreply.github.com>
2 participants
Update Envoy Commit
Update tests to address compiler warnings, new Envoy metric additions, server log scraping during expected error scenarios, and timing overhead under ThreadSanitizer (TSAN).