Race Condition and Concurrency Testing

Purpose

Many business invariants ("once per user", "balance cannot go negative", "limited stock") are enforced with check-then-act logic that two near-simultaneous requests defeat. This skill covers WHICH operations are race-prone, HOW to synchronize concurrent requests from inside Xalgorix with bounded concurrency, and WHAT proof looks like (a duplicated persistent effect, never N status codes).

Entry Conditions

• A state-changing operation whose business rule implies exactly-once or limit enforcement
• The operation can be triggered repeatedly in quick succession within scan policy

Race-Prone Operation Candidates

• Coupon / discount / gift-card redemption (limit: one per user)
• Payment, refund, withdrawal, transfer, balance operations
• Inventory reservation / limited-stock purchase
• Username/account claim, signup with uniqueness, email claim
• Invite acceptance (single slot), role change (grant/revoke races)
• Quota enforcement: storage, usage, API rate budgets, download limits
• OTP usage / verification marking, password reset consumption
• File processing on the same object, double-processing of an async job
• Vote / review / like counters; reward claiming; trial start

Signals in code-less form: any "check then act" wording in error messages ("You have already used this coupon"), counter fields returned by the API, or limits that appear to update AFTER a response.

Methodology

baseline single request
-> identify the invariant (what must be true about final state)
-> synchronize N concurrent identical requests
-> observe FINAL backend state (re-fetch, never trust the responses alone)
-> repeat enough batches to distinguish race from noise
-> prove persistent impact