systematic-debugging

# Systematic Debugging for OpenMetadata Structured 4-phase debugging process. Stops you from guessing and forces root cause identification. ## When to Use - Test failures with unclear cause - Build errors after dependency or schema changes - Runtime exceptions in backend, frontend, or ingestion - Issues that persist after 2+ fix attempts ## Phase 1: Gather Evidence **Do not change any code yet.** Only observe and collect data. 1. **Read the full error** — not just the last line. Stack traces, build logs, test output. 2. **Reproduce reliably:** ```bash # Java mvn test -pl <module> -Dtest=FailingTest#failingMethod # Python source env/bin/activate && cd ingestion python -m pytest tests/unit/path/to/test.py::test_name -v # TypeScript cd openmetadata-ui/src/main/resources/ui yarn test path/to/test.spec.ts # E2E yarn playwright:run --grep "test name" ``` 3. **Check what changed recently:** ```bash git log --oneline -20 git diff HEAD~5 -- <relevant-directory> ``` 4. **Document findings:** Write down the exact error, when it started, and what you've observed. ## Phase 2: Form Hypotheses Based on the evidence, list **2-3 possible causes** ranked by likelihood: ``` 1. [Most likely] Schema change in X broke generated model Y Evidence: error mentions field Z, git log shows schema modified 3 commits ago 2. [Possible] Dependency version mismatch after recent upgrade Evidence: ClassNotFoundException for new API 3. [Unlikely] Test environment state pollution Evidence: test passes in isolation but fails in suite ``` **Do not jump to fixing yet.** Verify the top hypothesis first. ## Phase 3: Verify Root Cause Test your top hypothesis with the **smallest possible experiment:** - **Read the suspected code** — don't guess what it does - **Add targeted logging** or use a debugger if needed - **Check one hypothesis at a time** — don't make multiple changes simultaneously ### Common OpenMetadata Root Causes | Symptom | Likely Cause | Verification | |---------|-------------|--------------| | `ImportError` in Python | Models not regenerated after schema change | `make generate` then retry | | `TypeScript compile error` on generated types | Schema changed, types not rebuilt | `yarn parse-schema` then retry | | Java `NullPointerException` in entity | Missing field in Flyway migration | Check `bootstrap/sql/migrations/` | | Test passes alone, fails in suite | Shared state mutation between tests | Run with `--forked` (Java) or `-x` (pytest) | | `404 Not Found` on API endpoint | Missing `@Path` annotation or route config | Check resource class registration | | UI component renders blank | Missing i18n key | Check `locale/languages/en-us.json` | | `Connection refused` in integration test | Docker service not running | `docker compose -f docker/development/docker-compose.yml ps` | ## Phase 4: Fix and Verify Now — and only now — write the fix: 1. **Fix only the root cause.** Don't "improve" surrounding code. 2. **Run the failing test** — it must pass now. 3. **Run the broader test suite** for the affected module to check for regressions. 4. **Explain why** the fix works in your commit message or response. ## Escalation Rules - **After 3 failed fix attempts:** Stop trying random fixes. Re-examine your hypotheses. The root cause is likely different from what you think. - **After 5 failed attempts:** Question your assumptions about the architecture. Read more broadly — adjacent modules, recent PRs, dependency changelogs. - **If the fix requires changing test infrastructure:** Pause and discuss with the user. The problem might be in the test setup, not the code. ## Anti-Patterns - **Shotgun debugging:** Changing multiple things at once hoping something works. - **Symptom treating:** Adding `try/catch` or `if null` checks to suppress errors instead of fixing the cause. - **Blame the framework:** Before assuming a bug in Dropwizard, Pydantic, or React, verify your own code is correct. - **Skipping reproduction:** "I think I know what it is" — prove it with a failing test first.