Data isolation bugs are invisible until they're not

A data isolation bug is one of the few classes of bug that can pass a thorough manual QA pass and still be completely broken. If you're the only user testing a system, every query you run is scoped to you by default there's no second user's data around to leak into your view.

That's exactly what happened on a student progress tracker I built with FastAPI and Next.js. Every individual test looked fine: create a student, log progress, view the record, it all worked. The bug only appeared with two students active at once, and even then, only intermittently, depending on request timing.

The root cause was a query missing an explicit filter it fetched progress entries without scoping them strictly to the requesting student's ID. In isolation, that's a one-line fix. The harder part was recognizing that the bug existed at all, since nothing about the single-user testing flow would ever surface it.

The fix that mattered wasn't a UI patch. It was moving the scoping logic into the query layer itself, so that no matter which route called it, a student could only ever receive their own records back. That's a stronger guarantee than 'the frontend won't show you someone else's data' it means the API itself cannot return it, regardless of how the request is shaped.

The broader lesson: any system with more than one user needs testing scenarios that specifically simulate concurrent, cross-user activity not just repeated single-user happy paths. It's a small addition to a test plan that catches a category of bug that's otherwise nearly impossible to find by accident.