debugging-and-error-recovery

Reproduce the failure reliably first, then localize which layer is failing, reduce to a minimal case, and fix the root cause rather than the symptom. Finish by adding a regression test that fails without the fix and running the full suite to check for regressions.

Use git bisect: mark the current commit as bad and a known-working commit as good, then let git checkout midpoint commits while you run the failing test at each step. You can automate it with git bisect run followed by your test command.

Classify it as timing-dependent, environment-dependent, state-dependent, or truly random, then apply the matching strategy: add timestamps and artificial delays for races, compare environments and data, check for leaked shared state, or add defensive logging and alerts.

No. Flaky tests mask real bugs, so fix the flakiness or understand why it is intermittent before moving on. Skipping failing tests to build new features lets errors compound and makes later steps wrong.

Remove instrumentation once the bug is fixed and a regression test guards against recurrence, or when the log is only useful during development. Always remove logs containing sensitive data, but keep permanent instrumentation like error boundaries and API error logging.