Lab 8.1 — Find and Reproduce a Real JIRA Issue
Lab type: Research & Reproduce
Estimated time: 2–4 hours (actual time varies by issue)
Step 1 — Find a Good Candidate
Go to: https://issues.apache.org/jira/projects/TEZ
Filter:
- Status: Open
- Priority: Minor or Trivial
- Component: tez-dag or tez-runtime-library
- Resolution: Unresolved
Look for issues with:
- A small reproduction case described in comments
- No existing "Patch Available" attachment
- Last comment less than 1 year old
Step 2 — Read Everything
For your chosen issue, read:
- The original description
- Every comment (some comments contain critical reproduction steps)
- Any attached patches (even if they were rejected — understand why)
- Related issues in the "is blocked by" / "depends on" links
Answer for your issue:
| # | Question |
|---|---|
| 1 | What is the exact symptom? (Exception? Wrong result? Performance regression?) |
| 2 | Which Tez class is implicated? Which method? |
| 3 | Under what conditions does the bug occur? |
| 4 | Is there a unit test that would catch this if it existed? |
Step 3 — Reproduce the Bug
For a unit-test-reproducible bug:
cd ~/tez-src
# Write a test that fails
mvn test -pl tez-dag -Dtest=TestVertexImpl#testMyReproduction -q 2>&1 | tail -20
For a configuration-dependent bug, write a minimal local-mode DAG that triggers it.
Record:
- The exact exception and stack trace
- Which class and line number triggers it
- Whether it is deterministic or intermittent
Step 4 — Map the Root Cause
Trace from the symptom to the line of code that is wrong:
- Start with the exception message
- Find the throw site in source code
- Walk backwards through the call stack
- Identify the single line that is wrong (the real fix site is often 10 lines above the throw site)
Step 5 — Verify Your Understanding
Post a comment on the JIRA (be professional and concise):
I was able to reproduce this issue on Tez trunk (commit <hash>) with the
following minimal test case:
[paste test code or reproduction steps]
The root cause appears to be [one sentence description] at
[ClassName.java:line]. I am working on a patch.
This establishes you as working on the issue and prevents duplicate work.
Questions
- How long did it take you to go from "reading the JIRA" to "reproducing the bug"?
- Was the root cause where you expected it based on the stack trace, or did you have to trace further?
- Is there a comment in the code near the bug site that explains the intended behavior? Was the comment wrong?