Fix voucher redemption race condition using pessimistic locking

[ArnavBallinCode]

Fix: Voucher Redemption Race Condition

Fix voucher redemption race condition using pessimistic locking

Problem:

• Voucher validation occurred before acquiring database lock
• Multiple concurrent requests could all see voucher as 'available'
• Led to over-redemption beyond max_usages limit

Solution:

• Added select_for_update() to acquire row-level lock before validation
• Added explicit availability check after lock acquisition
• Ensures only one thread can validate voucher state at a time

Fixes #1398

• Tested: 5 concurrent threads redeemed voucher with max_usages=3

Summary by Sourcery

Prevent race conditions during voucher redemption by validating availability under a database row lock.

Bug Fixes:

• Ensure voucher availability is checked under a row-level lock to prevent over-redemption under concurrent requests.

Enhancements:

• Use pessimistic locking on voucher rows when computing availability in the cart service.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Implements pessimistic row-level locking and post-lock availability validation for voucher redemption to prevent race-condition-based over-redemption in the cart service.

Sequence diagram for concurrent voucher redemption with pessimistic locking

sequenceDiagram
    actor User1
    actor User2
    participant CartService1
    participant CartService2
    participant DB

    User1->>CartService1: redeem_voucher(voucher_code)
    User2->>CartService2: redeem_voucher(voucher_code)

    CartService1->>DB: SELECT voucher FOR UPDATE
    activate DB
    DB-->>CartService1: locked Voucher row
    deactivate DB

    CartService2->>DB: SELECT voucher FOR UPDATE
    activate DB
    DB-->>CartService2: waits (row lock held)

    CartService1->>CartService1: compute cart_count, v_avail
    CartService1->>CartService1: if v_avail < requested_count: raise CartError
    CartService1->>DB: update voucher.redeemed
    DB-->>CartService1: commit transaction, release lock

    deactivate DB

    DB-->>CartService2: locked Voucher row (after lock released)
    CartService2->>CartService2: refresh redeemed, compute cart_count, v_avail
    CartService2->>CartService2: if v_avail < requested_count: raise CartError
    CartService2->>DB: update voucher.redeemed or abort
    DB-->>CartService2: commit/rollback

    CartService1-->>User1: success or CartError
    CartService2-->>User2: success or CartError

Loading

Flow diagram for updated _get_voucher_availability voucher locking and validation

flowchart TD
    A["Start _get_voucher_availability"] --> B["Iterate over voucher_use_diff (voucher, count)"]
    B --> C["Lock voucher row: select_for_update by pk"]
    C --> D{"voucher.valid_until is not None and voucher.valid_until < now_dt?"}
    D -- Yes --> E["Raise CartError voucher_expired"]
    D -- No --> F{"voucher.reusable or not voucher.is_valid_for_event(event)?"}
    F -- Yes --> G["Raise CartError voucher_invalid_for_event"]
    F -- No --> H["Compute redeemed_in_carts excluding ExtendOperation positions"]
    H --> I["cart_count = redeemed_in_carts.count"]
    I --> J["v_avail = voucher.max_usages - voucher.redeemed - cart_count"]
    J --> K{"v_avail < count?"}
    K -- Yes --> L["Raise CartError voucher_redeemed (over-redemption prevented)"]
    K -- No --> M{"cart_count > 0?"}
    M -- Yes --> N["Add voucher to _voucher_depend_on_cart"]
    M -- No --> O["Skip dependency tracking for this voucher"]
    N --> P["vouchers_ok[voucher] = v_avail"]
    O --> P
    P --> Q{"More vouchers to process?"}
    Q -- Yes --> B
    Q -- No --> R["Return vouchers_ok and finish"]

Loading

File-Level Changes

Change	Details	Files
Ensure voucher availability is validated under a database row-level lock to prevent race conditions in concurrent redemptions.	Replace non-locking voucher.refresh_from_db() call with a select_for_update() query to lock the voucher row before further checks. Compute remaining voucher availability (max_usages - redeemed - in-cart count) under the acquired lock. Add an explicit availability check comparing requested usage count against remaining availability and raise a voucher_redeemed error when insufficient.	app/eventyay/base/services/cart.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#1398	Move voucher availability validation so it is performed under a proper database lock to remove the race condition in concurrent voucher redemptions.	✅
#1398	Ensure that the voucher max_usages limit is strictly enforced under concurrent usage (e.g., a voucher with max_usages=3 cannot be successfully redeemed more than 3 times).	✅

Possibly linked issues

• Bug: Voucher Redemption Race Condition #1398: PR acquires row-level lock and revalidates availability, directly fixing the voucher over-redemption race condition described.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[mariobehling]

The docker build is failing. Please check.

[Copilot]

Pull request overview

This PR fixes a race condition in voucher redemption that allowed multiple concurrent requests to over-redeem vouchers beyond their max_usages limit. The fix implements pessimistic locking using Django's select_for_update() to ensure atomic validation and redemption of vouchers.

Key Changes:

• Replaced refresh_from_db() with select_for_update().get() to acquire row-level locks before validation
• Added explicit availability check after lock acquisition to prevent over-redemption
• Ensures thread-safe voucher validation within database transactions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ArnavBallinCode]

The docker build is failing. Please check.

It was due to some network issue...
working now...