Describe
The test test_cpu_mem_from_psutil fails on ppc64el because it assumes that the normalized CPU usage value (system.cpu.total.norm.pct) is always strictly less than 1.0.
On some systems, however, the value can legitimately be exactly 1.0, which causes the assertion to fail.
Steps to reproduce
Run the test suite on a ppc64el environment:
j = i * i
data = next(metricset.collect())
The test assertion:
assert 0 < data["samples"]["system.cpu.total.norm.pct"]["value"] < 1
Observed behavior
On ppc64el, the collected value can be:
1.0
which leads to a test failure:
E assert 1.0 < 1
Expected behavior
The normalized CPU value is expected to be within the valid range:
0 <= value <= 1
A value of 1.0 appears to be a valid and expected edge case in some environments.
Environment
Architecture: ppc64el
Dependency: psutil
Library: Elastic APM Python client
OS / Python version: 3.14/3.15
Analysis / Notes
The metric is based on CPU time deltas (via psutil.cpu_percent() / cpu_times_percent()).
On some architectures (including ppc64el), timing resolution and scheduling effects can make it more likely that the measured interval contains effectively no idle time, resulting in a normalized value of exactly 1.0.
This appears to be a valid edge case rather than an indication of incorrect behavior.
Suggested fix
The assertion could be relaxed slightly to include 1.0:
assert 0 <= value <= 1
Why this change
Keeps the test valid across architectures
Avoids false negatives in CI on non-x86 systems
Still preserves correctness bounds of the metric
Optional alternative
If stricter lower-bound behavior is intended, the test could instead focus on ensuring only that the value is bounded:
assert value <= 1
Summary
This looks like a harmless but architecture-sensitive edge case where 1.0 is a valid result. Relaxing the strict inequality would likely improve portability of the test suite across platforms.
perhaps a duplicate of #2612
Describe
The test test_cpu_mem_from_psutil fails on ppc64el because it assumes that the normalized CPU usage value (system.cpu.total.norm.pct) is always strictly less than 1.0.
On some systems, however, the value can legitimately be exactly 1.0, which causes the assertion to fail.
Steps to reproduce
Run the test suite on a ppc64el environment:
The test assertion:
assert 0 < data["samples"]["system.cpu.total.norm.pct"]["value"] < 1Observed behavior
On ppc64el, the collected value can be:
1.0which leads to a test failure:
E assert 1.0 < 1Expected behavior
The normalized CPU value is expected to be within the valid range:
0 <= value <= 1A value of 1.0 appears to be a valid and expected edge case in some environments.
Environment
Architecture: ppc64el
Dependency: psutil
Library: Elastic APM Python client
OS / Python version: 3.14/3.15
Analysis / Notes
The metric is based on CPU time deltas (via psutil.cpu_percent() / cpu_times_percent()).
On some architectures (including ppc64el), timing resolution and scheduling effects can make it more likely that the measured interval contains effectively no idle time, resulting in a normalized value of exactly 1.0.
This appears to be a valid edge case rather than an indication of incorrect behavior.
Suggested fix
The assertion could be relaxed slightly to include 1.0:
assert 0 <= value <= 1
Why this change
Keeps the test valid across architectures
Avoids false negatives in CI on non-x86 systems
Still preserves correctness bounds of the metric
Optional alternative
If stricter lower-bound behavior is intended, the test could instead focus on ensuring only that the value is bounded:
assert value <= 1Summary
This looks like a harmless but architecture-sensitive edge case where 1.0 is a valid result. Relaxing the strict inequality would likely improve portability of the test suite across platforms.
perhaps a duplicate of #2612