debugging-systematic

Follow a four-phase process: reproduce the issue reliably, gather evidence like full stack traces and logs, form a specific testable hypothesis, then design experiments that prove or disprove it. Only implement a fix after the root cause is confirmed with evidence.

Intermittent failures usually indicate race conditions, shared mutable state, or timing dependencies. Isolate the failing component, add timestamped instrumentation around async operations, and check whether tests share global state that leaks between runs.

Run git bisect start, mark the current broken commit with git bisect bad, and mark a known working commit with git bisect good. Git checks out intermediate commits for you to test, binary-searching until it identifies the exact commit that introduced the regression.

This pattern typically signals a race condition or timing issue, since debuggers change execution timing. Look for async operations completing in unexpected order, missing awaits, or shared state accessed concurrently, then add logging with timestamps to confirm.

Ask for help after roughly two hours of systematic investigation, when the issue involves an unfamiliar subsystem, or when the reproducer is inconsistent. Prepare a written summary with reproduction steps, evidence gathered, hypotheses ruled out, and environment details first.