fix-failing-test

name	fix-failing-test
description	Fix a failing test in this C++/Bazel/Python project. Use when a test is red, flaky, or crashes (segfault, assertion, timeout). Covers: reproducing the failure, root-cause analysis, surgical fix, and verification. Trigger phrases: fix failing test, test is broken, test crashes, test flakes, make test pass.
argument-hint	test target or test name, e.g. //src/socom/test/unit:socom_test

Fix Failing Test

When to Use

• A Bazel test target is failing or flaky
• A test crashes (segfault, abort, timeout, exit 130)
• You need to make a specific test pass without breaking others

Procedure

1. Reproduce the Failure

# Run the specific test in isolation
bazel test <target> --test_output=all

# For flaky tests, run multiple times
bazel test <target> --runs_per_test=5 --test_output=all

• Capture the full error message, assertion, or signal (SIGSEGV, SIGABRT, exit 130).
• Note whether the failure is deterministic or intermittent (flaky).
• Consider installing the stress apt package and using the stress command to increase system load and make timing-sensitive flakes more likely to reproduce.

2. Read the Test and Production Code

• Open the test file and the unit(s) under test.
• Understand what the test is asserting and the expected sequence of operations.
• For C++ tests: check gtest assertions, mock expectations, and RAII lifetimes.
• For Python tests: check pytest fixtures in conftest.py and any vsomeip.json configs.

3. Classify the Failure

Symptom	Likely Cause
Assertion failure on state	Wrong initial state or missed transition
Crash / SIGSEGV	Use-after-free, dangling ref, uninitialized memory
Mock expectation not met	Missing call, wrong order, or wrong argument matcher
Timeout / deadlock	Missing notify, wrong condition variable, lock inversion
Flaky (passes sometimes)	Race condition, reconnect/retry timing, test isolation leak

4. Check Repo Memory

• Read /memories/repo/ for known flaky-test patterns in this codebase before deep-diving into the code. Known patterns are recorded there to avoid re-discovering them.

5. Implement the Fix

• Make the minimum change that fixes the root cause.
• Do not change unrelated code, add logging, or refactor.

6. Verify

# Confirm the target test passes
bazel test <target> --test_output=all

# Run the full test suite to check for regressions
bazel test //...

• For flaky fixes: run several times (--runs_per_test=10) to confirm stability and optionally use the stress command to increase system load and make timing-sensitive flakes more likely to reproduce.

7. Record New Patterns

• If the root cause was non-obvious or flaky, add a bullet to the relevant file under /memories/repo/ so future agents avoid the same investigation.

Project-Specific Notes

• Build system: Bazel — always use bazel test, not direct binary execution, to get correct runfiles and sandbox.
• Integration tests: live under //tests/integration; require two daemons (gatewayd + someipd) and vsomeip config from tests/integration/vsomeip-local.json.
• Python tests: use py_pytest rule; run with bazel test //tests/integration:integration --test_output=all.
• License headers: any new source file must include the Apache 2.0 header from AGENTS.md.