Overview
Through a structured error analysis and root cause localization process, automatically generate minimal diff format fix patches and regression prevention test cases, achieving end-to-end automated handling from error symptoms to a complete fix solution.
Use Cases
- Encounter error symptoms such as program crashes, thrown exceptions, and test failures that need analysis
- Need to locate the root cause of a bug (especially issues introduced by code changes)
- Need to generate code fix patches that conform to engineering specifications
- Need to create executable regression prevention test cases
- Need a complete bug analysis report (including root cause, fix, tests, and prevention suggestions)
Quick Reference
| Scenario | Localization Method | Applicable Conditions |
|---|---|---|
| General bug analysis | Top-down tracing method | No clear code change/PR information |
| Bug introduced by code changes | Git bisection method | Has code_change_info, need to locate the specific PR/commit |
| Error Code | Meaning | Handling Method |
|---|---|---|
| E001 | Input information is missing or cannot be parsed | Supplement required inputs (error_phenomenon/reproduce_steps) |
| E002 | Root cause is vague and cannot be accurately located | Provide more context information or code change information |
| E003 | Patch generation failed | Confirm the root cause has been locked down and check the code context |
| E004 | Test case generation failed | Confirm the fix patch is valid and specify the test framework |
Core Capabilities (Action + Result, No Overlap/No Out of Scope)
- Parse multilingual error symptoms and validate the completeness and validity of required input information
- Use thetop-down tracing methodfor general scenarios, and use theGit bisection methodfor code change/PR scenarios to locate the bug root cause and verify the reproducibility of the root cause
- Generate a minimal diff format code fix patch for the root cause, validate patch syntax correctness, and follow engineering development specifications
- Create directly executable regression prevention test cases for mainstream test frameworks, covering normal/boundary/exception core scenarios
- Output a structured Markdown format Bug analysis report, including error symptom description, reproduction steps, root cause analysis, fix patch, test cases, and prevention suggestions
Workflow (Steps + Validation + Interruption + Feedback, Directly Executable by Agent)
Step 1: Information Collection and Validation
✅ Validation Point: Check whether the required inputs (error_phenomenon/reproduce_steps) are complete and recognizable ❌ Interruption Condition: Missing required inputs / error symptom cannot be parsed (such as garbled text or incomplete) → throw error codeE001and interrupt 📝 Feedback: Output "Information collection completed, can enter the root cause analysis stage / Missing required inputs, error code E001"
Step 2: Root Cause Analysis and Confirmation
✅ Validation Point: The root cause is reproducible and accurately locked down to the specificcode line/file/PR/commit record ❌ Interruption Condition: Insufficient information causes the root cause to be vague and impossible to accurately locate → throw error codeE002and interrupt 📝 Feedback: Output "Root cause located: XXX (related PR/commit: XXX) / Root cause ambiguous, error code E002"
Locating method (the Agent automatically selects based on the input, strengthening Git bisection to locate the PR/commit)
Method 1: Top-down tracing method (general scenarios, no clear code change/PR information)
- Analyze the error stack trace to locate the specific line of code/file that throws the exception/triggers the error
- Check whether the input parameters, data flow, and dependency calls at that location meet business expectations
- If the input/dependency is abnormal, trace the data source/caller upstream level by level
- Repeat the above steps until the root cause is found (the location where the data/logic first becomes abnormal)
Method 2: Git bisection locating (scenarios where a bug is introduced by a code change/PR, with the core focus on locating the problematic PR/commit)
- Based on the input code_change_info, confirmthe last normal version/PR/commit before the bug appeared、the first abnormal version/PR/commit where the bug appeared
- Execute the Git bisection commands in sequence:
git bisect start→git bisect bad [异常版本/提交哈希]→git bisect good [正常版本/提交哈希] - Git automatically narrows the investigation scope and locatesthe specific commit record/associated PR that introduced the bug(the only change record in the bisection result)
- Analyze the code changes of the target commit/PR, pinpoint the root-cause line of code, and verify: after rolling back that commit/PR, confirm whether the bug disappears
- If multiple PRs/commits are involved, sort them by impact level and provide a method for verifying them one by one
Step 3: Minimal Diff format patch generation and validation
✅ Validation point: The patch is in standard diff format, with minimal modification granularity, no syntax errors, and only fixes the root cause ❌ Interruption condition: Root cause not pinpointed / no valid code context → throw error codeE003and interrupt 📝 Feedback: Output "Diff format fix patch generated, X modifications in total / Patch generation failed, error code E003"
Patch generation principles (mandatory compliance)
- Minimal modification: only modify code related to the root cause, with no unrelated logic/format changes
- Root-cause fix: solve the essence of the problem, rather than temporarily bypassing the surface problem
- Defensive programming: add input validation, boundary checks, and exception capture logic when necessary
- Engineering standards: comply with project coding standards, and do not introduce new syntax/logic issues
- Traceability: add a single-line comment at key fix points, explaining the reason for the fix and the associated root cause
Step 4: Regression prevention test case generation and validation
✅ Validation point: The test cases can be executed directly, cover core scenarios related to the root cause, and match the test framework actually used by the project ❌ Interruption condition: No valid fix patch / no test framework specified → throw error codeE004and interrupt 📝 Feedback: Output "Regression prevention test cases generated, X in total (adapted to XXX framework) / Test case generation failed, error code E004"
Core requirements for test cases
- Reproducible: can precisely reproduce the original bug (execution fails before the fix)
- Verifiable: passes after the fix, and can effectively verify the fix effect of the patch
- Full coverage: covers normal scenarios, boundary scenarios, and abnormal scenarios related to the root cause
- Executable: no syntax errors, and adapted to mainstream test frameworks (gtest/pytest/JUnit/GoTest/Jest/Vue Test Utils)
Output format (structured Markdown, machine + human friendly, fixed template must not be modified arbitrarily)
Bug Analysis Report
1. Error Symptoms
- Error description: [Clearly describe the error type, error message, impact scope, and related business scenario]
- Reproduction steps: [Step-by-step reproduction method, including runtime environment, test data, operation steps, and related version]
- Input validation: [Pass/Fail; if failed, specify the error code + specific reason]
- Code change information: [PR/commit/branch information extracted from the input, with key information for binary search localization marked]
2. Root Cause Analysis
- Root cause localization: [Specific root cause, such as division by zero error/null pointer exception/logic judgment error; if related to a PR/commit, specify the hash/number]
- Localization method: [Top-down tracing method / Git bisection method (related PR: XXX, commit hash: XXX)]
- Tracing process: [Briefly describe the execution process of the data flow/call chain/Git bisection method, and mark the key steps that pinpoint the root cause]
- Impact scope: [Affected code modules/PRs/branches/business scenarios/user groups]
3. Minimized Diff Format Fix Patch
[Standard diff format, including file path, line number, and modification content; add comments to key fix points]
diff --git a/.github/workflows/nightly_benchmarks.yaml b/.github/workflows/nightly_benchmarks.yaml
index 123456..789abc 100644
--- a/.github/workflows/nightly_benchmarks.yaml
+++ b/.github/workflows/nightly_benchmarks.yaml
@@ -15,6 +15,10 @@
- name: Install dependencies
run: |
pip install -e .
+ # 安装msprobe相关依赖（修复根因：PR#4241引入的msprobe功能需要这些依赖）
+ pip install mindstudio-probe==8.3.0 || echo "msprobe installation skipped"
+ pip install tb_graph_ascend || echo "tb_graph_ascend installation skipped"
4. Regression Prevention Test Cases
[Executable test code, adapted to the testing framework actually used by the project, covering normal/boundary/exception scenarios]
# 示例：pytest框架测试用例
def test_bug_fix_reproduction():
"""复现原始bug（修复前执行失败）"""
# 测试代码...
assert result == expected
def test_bug_fix_validation():
"""验证修复效果（修复后执行通过）"""
# 测试代码...
assert fixed_result == expected
def test_edge_cases():
"""边界场景测试"""
# 测试代码...
pass
5. Prevention Recommendations
- Code level: [Code improvement recommendations targeting the root cause, such as adding parameter validation, exception handling, etc.]
- Process level: [Development process improvement recommendations, such as code review points, test coverage requirements, etc.]
- Tool level: [Tool or monitoring recommendations, such as static analysis, logging enhancement, etc.]