Home
Feed

Extend

Hashnode Pro
Hashnode for Agents

Resources

The foreword
Hashnode gql skill

Buildful - AI coding agent that delivers frontier-level results at a fraction of the cost Bug0 - The AI-native e2e QA regression testing Hackathons Changelog Brand @hashnode on X Hashnode on LinkedIn Support - hello+support@hashnode.com Code of Conduct Terms Privacy Sitemap

Search Hashnode

Search posts, tags, users, and pages

Discussion on "One Row. Two Winners. The Concurrency Bug That Fooled My Tests" | Hashnode

Feed/

Discussion

Omar Moustafa

A full-stack developer, Python expert and tech-lover.

3d ago

One Row. Two Winners. The Concurrency Bug That Fooled My Tests

25 requests. One database row. Two successful claims. Wait, what? Ever built something, tested it, watched every test pass, and thought, yep, this is solid? Yeah. Same here. Until I discovered that my

omarcodes.io10 min read

#appwrite #concurrency #debugging #backend #software-engineering

Responses3

Markdown supported · ⌘↵ to post

Seedance AI

Seedance AI creative notes on video workflows, prompts and original visual examples.

3d ago

Classic phantom read and race condition scenario. Relying on application-level locks without explicit serializable isolation or atomic update constraints almost always breaks under production traffic.

yeah, the surprising part was seeing both requests succeed even inside transactions. it pushed me to make the database enforce the invariant explicitly, using deterministic event IDs, rather than assume the transaction alone was enough. the concurrent tests were what exposed the gap.

Omar Moustafa

A full-stack developer, Python expert and tech-lover.

3d ago

Seedance AI

Seedance AI creative notes on video workflows, prompts and original visual examples.

2d ago

Race conditions that slip past standard test suites usually point to transaction isolation level assumptions. Solid write-up on catching state collisions.