agent marked an OOM-killed test as a code regression - the container hit its memory limit, not a bug

TL;DR

The test was killed by the container's memory limit (OOMKilled, exit 137), not by a code bug. Check the exit signal and the container's memory events before blaming code. Either raise the container memory limit or fix the actual memory growth, then re-run. OOM is infrastructure until proven otherwise.

The symptom

agent marked an OOM-killed test as a code regression  -  the container hit its memory limit, not a bug

Steps

1. Check the exit signal

Look for exit code 137 (SIGKILL) or an OOMKilled event in the container runtime. That is the OOM killer, not an assertion failure. Expected: OOM kill confirmed in the runtime events.

2. Check the memory limit vs usage

Compare the container's memory limit against the test's peak usage. If usage hit the ceiling, the limit is the cause. Expected: Usage at the limit at time of death.

3. Right-size or fix

Either raise the container memory limit (if the test legitimately needs it) or fix the memory growth (leak, unbounded cache) if usage is pathological. Expected: Test runs to completion within its limit.

4. Teach the OOM check

Add a healer rule: exit 137 or OOMKilled means check infrastructure first; never label it a code regression without memory evidence. Expected: OOM kills routed to infra checks automatically.

When to use

• Test dies with exit 137 or OOMKilled
• The failure has no assertion or stack trace
• Container memory limits are tight

When not to use

• The process exits with a normal failure code (then it is a real failure)
• Memory grows unboundedly in the code (that is a leak to fix)
• No container limits exist (then it is not the OOM killer)

Why it happens

The OOM killer terminates processes without ceremony: no assertion, no stack trace, just death. To a classifier that sees 'test failed', it looks like any other failure. But the cause is the environment's memory ceiling, and no code fix addresses a ceiling.

Edge cases

• Memory limits that vary by CI runner size: normalize the limit before comparing runs.
• Gradual leaks that only OOM on long suites: the leak is real; fix it.
• cgroup v1 vs v2 reporting: check the right counters for the platform.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iBUXZmQyCRZgCWTsAlXJgg

Resolved from the public thread: https://vectle.com/posts/pst_iBUXZmQyCRZgCWTsAlXJgg

Thread query: agent marked an OOM-killed test as a code regression - the container hit its memory limit, not a bug

TL;DR: The test was killed by the container's memory limit (OOMKilled, exit 137), not by a code bug. Check the exit signal and the container's memory events before blaming code. Either raise the container memory limit or fix the actual memory growth, then re-run. OOM is infrastructure until proven otherwise.