// Investigate a RediSearch flaky-test report from a Jira key, CI failure, test id, or local logs. Use this to collect evidence, identify a supported root cause, and propose a real fix; if the evidence is insufficient, say so and ask for the missing data instead of suggesting workaround-only fixes or skip_until.
Compile the project to verify changes build successfully. Use this to verify your changes build properly together with the complete project and dependencies, and make sure to use it before running end to end tests.
Fix merge conflicts in a jj change and its ancestors, starting from the oldest conflict. Use this when a jj change or its ancestors have conflicts that need resolving.
Check code quality and formatting before committing changes. Use this to verify your changes meet our coding standards.
Guide for porting a C module to Rust. Use this when starting to port a C module to Rust.
Run Rust benchmarks and compare performance with the C implementation. Use this when you work on migrating C code to Rust and want to ensure performance is not regressed.
Run Rust tests after making changes to verify correctness. Use this when you want to verify your changes to Rust code.
| name | investigate-flaky-test |
| description | Investigate a RediSearch flaky-test report from a Jira key, CI failure, test id, or local logs. Use this to collect evidence, identify a supported root cause, and propose a real fix; if the evidence is insufficient, say so and ask for the missing data instead of suggesting workaround-only fixes or skip_until. |
Investigate a flaky-test report and propose a proper fix only when the evidence supports it.
$ARGUMENTS may contain any of:
MOD-...test_file:testName or test_file.py::test_nameCollect enough context to reason from facts:
Test Logs ... artifacts, if a CI URL/run id is providedFor GitHub Actions failures, prefer gh:
gh run view <run_id> --repo RediSearch/RediSearch --json url,headBranch,headSha,event,jobs
gh run view <run_id> --repo RediSearch/RediSearch --log-failed
mkdir -p /tmp/redisearch-flaky-<run_id>
gh run download <run_id> --repo RediSearch/RediSearch --dir /tmp/redisearch-flaky-<run_id>
CI failed-test artifacts commonly contain tests/**/logs/*.log*, bin/**/redisearch.so, and
bin/**/redisearch.so.debug.
Classify the failure before proposing a fix:
Separate proven facts from inference. Use language like "the logs show" for facts and "likely" or "possible" for hypotheses.
Trace from the failing assertion or exception to the code path that can produce it:
Env() settings, cluster
skips, and waits.Avoid stopping at "probably flaky" when the logs identify a specific race, missing wait, lifecycle conflict, or environment failure.
Propose a root-cause fix only when the cause is supported well enough to justify a code or test change. If the logs, source path, and failure signature do not support a specific cause, do not claim one.
A good fix proposal includes:
If the cause is unclear, say so plainly. Do not suggest workaround-only fixes, quarantine, or
skip_until from this skill. Instead, list the missing data needed, such as:
Test Logs ... artifactWhen the current evidence is not enough but the next failure could be made more informative, recommend a diagnostic PR instead of a workaround. A valid recommendation is to add focused debug logs, counters, state dumps, or richer test assertion messages, merge or run that instrumentation in CI for a few days, and use the next flaky occurrence to identify the root cause. Do not present this as "add logs and rerun once to find the root cause right away"; a focused local rerun can help, but the main goal is better evidence when the intermittent failure happens again.
Choose verification based on the proposed fix:
./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="<test_file>:<test_name>"
REDIS_STANDALONE=0 ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="<test_file>:<test_name>"
./build.sh RUN_UNIT_TESTS ENABLE_ASSERT=1 TEST=<unit_test_name>
cargo nextest run --manifest-path src/redisearch_rs/Cargo.toml -p <crate_name> <test_filter>
If the failure is timing-sensitive, recommend repeating the focused test enough times to gain confidence, and include any required environment variables from the CI failure.
End with: