You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[TEST] BasicCurlHttpTests.ElegantQuitQuick is flaky: a 20 ms wall clock budget on a shared runner #4342
BasicCurlHttpTests.ElegantQuitQuick asserts that FinishAllSessions() plus the client's destruction complete inside a 20 ms wall clock budget:
auto cost = std::chrono::system_clock::now() - beg;
ASSERT_TRUE(cost < std::chrono::milliseconds{20})
On a shared runner that budget is not something the code controls, and the test's own comment already says so ("Due to load on CI hosts (some take 10ms), we assert it is less than 20ms").
It passed and failed in the same job, on the same binaries
Second pass, same build directory, no rebuild between them:
925/1359 Test #925: ext.http.curl.BasicCurlHttpTests.ElegantQuitQuick ... ***Failed 0.76 sec
curl_http_test.cc:712: Failure
Value of: cost < std::chrono::milliseconds{20}
Actual: false
Expected: true
cost ms: 247 libcurl version: 0x81500
99% tests passed, 1 tests failed out of 1348
247 ms against a 20 ms budget, so it is not a marginal overshoot. The whole job then exits 8 and the PR goes red.
The bound has been 20 ms since #3198 (2024-12-18) and has not been revisited.
What could be done instead
Raise the bound. Cheapest, and it keeps the shape of the check, but it only moves the threshold a loaded runner can still cross.
Assert the behaviour rather than the duration. What [SDK] Do not frequently create and destroy http client threads #3198 was protecting is that the background thread wakes on shutdown instead of sitting out scheduled_delay_milliseconds_. A bound derived from that delay, say "well under scheduled_delay_milliseconds_" rather than a fixed 20 ms, states the invariant without pinning it to host speed.
Keep the timing check but take it out of the default ctest set, so a slow runner does not fail an unrelated PR.
I ran into it on #4331, whose diff touches only exporters/elasticsearch. Happy to send whichever of these you prefer.
Duplicate of #4265, which @dbarker filed on 2026-07-17 and which @yogarajalakshmi-s picked up on 2026-07-27. I should have searched before filing. The two measurements from here that bear on the fix, the 247 ms overshoot and the same job passing then failing on the same binaries, are now on #4265.
Activity
dbarker commentedon Aug 3, 2026
Thanks for reporting a sighting of this flaky test and analysis. Linking to #4265 as duplicate.
thc1006 commentedon Aug 3, 2026
Duplicate of #4265, which @dbarker filed on 2026-07-17 and which @yogarajalakshmi-s picked up on 2026-07-27. I should have searched before filing. The two measurements from here that bear on the fix, the 247 ms overshoot and the same job passing then failing on the same binaries, are now on #4265.