Overview
Through a structured error analysis and root cause localization process, automatically generate minimized 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
- When encountering error symptoms such as program crashes, thrown exceptions, or test failures that need analysis
- When the root cause of a bug needs to be localized (especially issues introduced by code changes)
- When a code fix patch that conforms to engineering standards needs to be generated
- When executable regression-prevention test cases need to be created
- When a complete bug analysis report is needed (including root cause, fix, tests, and prevention recommendations)
Quick Reference
| Scenario | Localization Method | Applicable Conditions |
|---|---|---|
| General bug analysis | Top-down tracing method | No clear code change/PR information |
| Bug introduced by code change | Git bisection method | Has code_change_info, needs to localize the specific PR/commit |
| Error Code | Meaning | Handling Method |
|---|---|---|
| E001 | Input information is missing or cannot be parsed | Supplement the required inputs (error_phenomenon/reproduce_steps) |
| E002 | Root cause is vague and cannot be accurately localized | Provide more context information or code change information |
| E003 | Patch generation failed | Confirm that the root cause has been locked down, and check the code context |
| E004 | Test case generation failed | Confirm that the fix patch is effective, 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 localize the bug root cause, and verify the reproducibility of the root cause
- Generate a minimized diff-format code fix patch for the root cause, validate the patch syntax correctness, and follow engineering development standards
- 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 recommendations
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 symptoms cannot be parsed (such as garbled text or incomplete) → throw error codeE001and interrupt 📝 Feedback: Output "Information collection completed, can proceed to 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 leads to a vague root cause that cannot be accurately localized → throw error codeE002and interrupt 📝 Feedback: Output "Root cause located: XXX (related PR/commit: XXX) / Root cause unclear, error code E002"
Locating methods (the Agent automatically selects based on the input, with emphasis on Git bisection to locate the PR/commit)
Method 1: Top-down tracing method (general scenarios, with 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 step by step
- Repeat the above steps until the root cause is found (the location where the data/logic first becomes abnormal)
Method 2: Git bisection locating (for scenarios where a code change/PR introduced a bug, the core task is 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/related 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 it: after rolling back that commit/PR, confirm whether the bug disappears
- If multiple PRs/commits are involved, sort them by impact and provide a method to verify them one by one
Step 3: Minimal Diff-format patch generation and validation
✅ Validation points: The patch is in standard diff format, has the minimal modification granularity, has no syntax errors, and fixes only the root cause ❌ Interruption condition: root cause not pinpointed / no valid code context → throw error codeE003and interrupt 📝 Feedback: Output "Diff-format fix patch has been generated, X modifications in total / Patch generation failed, error code E003"
Patch generation principles (mandatory compliance)
- Minimal modification: modify only code related to the root cause, with no unrelated logic/format changes
- Root cause fix: solve the essence of the problem, rather than temporarily working around the surface problem
- Defensive programming: add input validation, boundary checks, and exception-catching logic when necessary
- Engineering standards: comply with the project's coding standards and do not introduce new syntax/logic problems
- Traceability: add a single-line comment at key fix points explaining the reason for the fix and the related root cause
Step 4: Regression-prevention test case generation and validation
✅ Validation points: The test cases can be executed directly, cover the core scenarios related to the root cause, and match the test framework actually used by the project ❌ Interruption condition: no valid fix patch / test framework not specified → throw error codeE004and interrupt 📝 Feedback: Output "Regression-prevention test cases have been generated, X in total (adapted to the XXX framework) / Test case generation failed, error code E004"
Core requirements for test cases
- Reproducible: can accurately reproduce the original bug (execution fails before the fix)
- Verifiable: execution passes after the fix, effectively verifying the patch's fix effect
- Full coverage: cover normal scenarios, boundary scenarios, and abnormal scenarios related to the root cause
- Executable: no syntax errors, adapted to mainstream test frameworks (gtest/pytest/JUnit/GoTest/Jest/Vue Test Utils)
Output format (structured Markdown, machine- and human-friendly, fixed template not to be modified arbitrarily)
Bug Analysis Report
1. Error Symptoms
- Error description: [Clearly describe the error type, error message, scope of impact, 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 noted]
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, note the hash/number]
- Localization method: [Top-down tracing method / Git bisection (related PR: XXX, commit hash: XXX)]
- Tracing process: [Briefly describe the data flow/call chain/Git bisection execution process, and note the key steps that pinned down the root cause]
- Scope of impact: [Affected code modules/PRs/branches/business scenarios/user groups]
3. Minimal Diff Format Fix Patch
[Standard diff format, including file paths, line numbers, and modified content; add comments explaining 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.]