Reproduce bug: Trigger the issue to generate trace data
To ensure the generated trace data is high-quality, verifiable, and easy to analyze, follow this structured process:
6.1 Bug Type Identification
Before attempting reproduction, first identify the bug type:
| Type | Keywords | Reproduction Strategy |
|---|
| CRASH | "raises", "throws", "Error" | Trigger the exact exception, ensure trace contains full error stack |
| BEHAVIOR | "doesn't work", "incorrect", "should" | Use assertions to prove incorrect behavior, compare expected vs actual output |
| PERFORMANCE | "slow", "N+1", "query count" | Record performance metrics, compare baseline vs stress test trace data |
6.2 Reproduction Hierarchy
Choose reproduction entry point by priority:
Level 1 - User Entry Point (Preferred)
- Start from the actual API/CLI/UI operation the user invokes
- Examples:
POST /api/login, cli_tool --arg value
- Advantage: Trace contains complete call chain from external request to internal error point
Level 2 - Public API (Fallback)
- Directly call internal public functions
- Examples: Java:
userService.authenticate(), Node.js: authController.login(), Python: User.objects.create_user()
Level 3 - Internal Function (Last Resort)
- Directly call the internal function causing the bug
- ⚠️ Must document in analysis why upper layers were skipped
6.3 Sidecar Reproduction Technique
Reuse existing test infrastructure rather than building from scratch:
- Explore existing tests: Use
grep -rn "bug keyword" tests/ to locate related test files
- Create sidecar test files: Create two new files in the related test directory:
test_reproduce_issue.<ext> - Bug reproduction scripttest_happy_path.<ext> - Happy path validation script
- Create helper scripts (optional): For complex logic, dynamically generate Python/Shell scripts
Forbidden: ❌ Creating Mock classes, ❌ Manually modifying sys.path, ❌ Skipping project standard startup procedures
6.4 Reproduction Script Specification
reproduce_issue.<ext> (Bug Reproduction Script):
import sys
def run_reproduction_scenario():
if bug_is_detected:
print("BUG_REPRODUCED: [error message]")
sys.exit(1)
else:
print("BUG_NOT_REPRODUCED")
sys.exit(0)
if __name__ == "__main__":
run_reproduction_scenario()
happy_path_test.<ext> (Happy Path Validation Script):
- Use the same environment setup as the reproduction script
- Call the same functionality with valid inputs
- Include substantive assertions
- Print
"HAPPY_PATH_SUCCESS" upon successful execution
6.5 Execute Reproduction Script and Collect Trace Data
- Run reproduction script:
python3 reproduce_issue.py
mvn test -Dtest=ReproduceIssueTest
npx jest reproduceIssue.test.js
- Collect traceId: Call
search_debug_traces(projectId, query="bug keyword", limit=1)
- Get call tree report: Use
get_trace_insight(projectId, traceId) to find [ERROR] nodes
6.6 Runtime Trace Verification
Checklist:
When trace is incomplete:
- Adjust reproduction script or entry point
- Check SDK configuration
- Use
diff_trace_execution to compare failed vs successful scenario traces
6.7 Reproduction Quality Gate
Before entering analysis phase, must pass these checks:
✓ reproduce_issue.<ext> consistently triggers the bug (non-zero exit code)
✓ happy_path_test.<ext> passes (zero exit code)
✓ Trace data contains complete error stack and key variable values
✓ Error type and location match the bug description
✓ Trace provides sufficient context information
Reproduction failure diagnosis:
- Did not fail as expected: Check script logic, input data, use
get_trace_insight to view execution path
- Unexpected failure: Check environment, dependencies, or script syntax, use
get_trace_insight to locate error point
Important: After each adjustment, re-run the reproduction script and collect new traces, then pass the quality gate again
