Consumer Wallet Rate-Limit Race-Condition Automation: A Limit That Two Requests Could Both Ignore at Once

A rate limiter built as "count how many attempts happened recently, and reject this one if that count is already too high" is intuitive and, under ordinary, one-at-a-time traffic, works exactly as intended. The design has a specific, easy-to-miss weakness the moment two attempts can arrive close enough together to both execute their own "count, then decide" sequence before either one's own attempt is written down: both requests see the same, not-yet-updated count, both conclude independently that the limit has not been reached, and both proceed — even in cases where the combined total, had it been checked as a single, indivisible operation, should have blocked the second one outright. The limiter is not wrong in its arithmetic; it is wrong in its timing.

Centriu Loop's consumer portal enforces a rate limit on how many times a single IP address may attempt to open a session within a given window, specifically to blunt automated probing. The previous implementation determined whether an address had exceeded its limit by counting matching rows in an audit-log table — a table that records sensitive operations across the product generally, not a structure purpose-built to enforce a hard concurrency guarantee.

That counting step and the decision that followed it were not wrapped in anything that would prevent a second request from reading the count before the first request's own attempt had been written down. Under ordinary, one-request-at-a-time traffic, this timing gap is invisible: each request's count reflects every attempt that came before it, because there is no overlap for the gap to matter within. Under genuine concurrency — multiple requests from the same address arriving close enough together — the gap becomes exploitable structurally, not through any cleverness on an attacker's part: request A reads the count, request B reads the same count before A's own attempt is recorded, and both independently and correctly conclude, based on the information each one had, that the limit had not yet been reached. Both proceed. The limiter's own arithmetic was never wrong; the sequence around it simply allowed multiple requests to act on the same, momentarily stale information.

The fix does not try to patch the existing check-then-write sequence with a faster count or a shorter window — both would narrow the race without closing it. Instead, the counting mechanism moved into the database itself, using a dedicated table built specifically for this purpose rather than the general-purpose audit log, and the count-and-record sequence for a given IP address is now serialized using a database-level advisory lock scoped specifically to that address's own hashed identifier, held for the duration of a single transaction. Any second request from the same address arriving while the first is still being processed must wait for that lock to release before it can perform its own count — at which point the first request's own attempt has already been recorded, and the second request sees a count that correctly includes it.

The fix was verified specifically under the condition that actually exposes the original defect: not a sequential series of requests, however many, but sixteen requests fired at the same address at the same time, confirming the limit held under genuine, deliberate concurrency rather than merely under the sequential traffic pattern that had made the original race invisible to ordinary testing.

Before the fix, an automated tool sending a burst of simultaneous requests from a single IP address could have several of them — not just the first — all read the rate limiter's count before any of their own attempts were recorded, and all proceed past a limit that, checked correctly, should have stopped every request beyond the first few. After the fix, the identical burst is serialized at the database level: each request's count-and-record sequence completes fully before the next one can begin its own check, so the limit holds exactly as configured regardless of how many requests arrive at the same instant.

Centriu Loop's consumer-portal rate limiter now enforces its configured limit correctly under genuine concurrent load, closing a race condition that previously allowed multiple simultaneous requests from the same address to each read a stale, not-yet-updated count and proceed together — verified specifically by firing 16 simultaneous requests and confirming the limit held.

This automation governs the internal concurrency-safety of Centriu Loop's own consumer-portal rate limiter — it does not change the limiter's own configured thresholds or windows, does not add a customer-facing setting, and does not affect rate limiting on any other Centriu Loop endpoint or any other Centriu product, which this fix does not touch.

Implementing a rate limit as "count recent attempts, then decide" in application code is straightforward to write and reason about under ordinary, sequential traffic — the risk is specific to genuine concurrency, which sequential manual testing rarely exercises and therefore rarely catches. Moving the count-and-decide sequence into the database itself, serialized with a lock scoped to exactly the resource being limited (here, one IP address), removes the timing gap entirely by making the check-and-record a single, indivisible operation — at the cost of needing to deliberately test under real concurrent load, since a sequential test cannot distinguish a correctly atomic limiter from one that merely got lucky.