debugging-and-error-recovery

Reproduce the failure reliably first, then localize which layer is failing and reduce to a minimal failing case. Fix the root cause rather than the symptom, add a regression test that fails without the fix, and verify the full suite passes before continuing.

Run git bisect start, mark the current commit as bad and a known working commit as good, then test each midpoint checkout. You can automate it with git bisect run followed by your focused test command to identify the offending commit.

Classify whether it is timing-dependent, environment-dependent, state-dependent, or truly random. Add timestamps or artificial delays for race conditions, compare environments and data states, run scenarios in isolation, and set up logging or alerts for the error signature.

Symptom fixes mask the underlying issue, which resurfaces elsewhere and compounds with later changes. Asking why the failure happens until reaching the actual cause, such as fixing a duplicating JOIN query rather than deduplicating in the UI, prevents recurrence.

No. Flaky tests mask real bugs, and pushing past failures compounds errors across subsequent work. Stop adding changes, investigate the timing, order dependence, or external dependencies causing flakiness, and fix it before resuming.

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