[test] Test_PushMetricsConcurrent fails on Windows 2025 GH runner #37104
Comments
|
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
The test is also failing outside of Windows 2025, but, per PR #37025 it seems more likely to fail on Windows 2025, see https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/runs/12678000508/job/35334640582#step:8:216 |
|
Interesting, thanks for the ping. I'm not really experienced with Windows Arch. Do you have any tips on how to debug the problem without a Windows machine? |
|
Hi @ArthurSens - scheduling and timing on Windows is really different than *nix. In this case I suspect that is the blasting of requests in goroutines done in the test that somehow is causing the trouble on Windows. Limiting the number of pending requests may help. |
…#37430) Fix open-telemetry#37104 This is more an artifact of the test firing an unbounded number of go routines each one making its own HTTP request. Although keepalive is enabled by default the code ends up not re-using many of the connections causing the many connections to end up in a TIME_WAIT state. In order to avoid this the test now limits the number of concurrent requests and has a small change to the actual code to facilitate re-use of existing TCP connections used by the HTTP client. Although there is a change to non-test code I don't consider this a bug worth changelog because no user of the component should reach such high burst of "push metrics" in any reasonable production scenario.
Component(s)
exporter/prometheusremotewrite
Describe the issue you're reporting
Detected via #37025 - the test is failing consistently on the Windows 2025 GH runner. Opening this issue so we can enable tests on Windows 2025 while this test failure is investigated.
Related to #37024
The text was updated successfully, but these errors were encountered: