# Race Condition Testing

Application-level concurrency abuse - identify race-prone business operations (coupons...

- Repository: https://github.com/xalgorix/xalgorix (1285 stars)
- Category: Business
- License: Apache-2.0
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add xalgorix/xalgorix --skill race-condition-testing -g -a claude-code -y`
Codex: `npx skills add xalgorix/xalgorix --skill race-condition-testing -g -a codex -y`
Cursor: `npx skills add xalgorix/xalgorix --skill race-condition-testing -g -a cursor -y`
Gemini CLI: `npx skills add xalgorix/xalgorix --skill race-condition-testing -g -a gemini-cli -y`

## Description

Application-level concurrency abuse - identify race-prone business operations (coupons, payments, withdrawals, quotas, OTP, invites) and synchronize parallel requests with bounded concurrency to prove a duplicated persistent effect: double-spend, limit overrun, duplicate creation, TOCTOU.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

```text
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
```

The rest: https://github.com/xalgorix/xalgorix/blob/HEAD/internal/tools/skills/data/application-security/race-condition-testing/SKILL.md