Files
EpicNext-Cms/docs/superpowers/evidence/2026-09-05-voucher-reservation.md
T
Simo 8e54cdbc6a
CI / check (pull_request) Successful in 1m46s
CI / deploy (pull_request) Skipped
CI / e2e (pull_request) Skipped
fix(vouchers): reserve claims atomically before reward dispatch
2026-09-05 10:18:44 +02:00

1.4 KiB

Voucher claim reservation

The public redemption action now serializes claims on the selected voucher row. It validates amount, capacity and expiration, locks the duplicate-claim read, inserts the used row, increments usage and stores the audit intent in one transaction. No reward dispatch occurs until the transaction resolves successfully. A commit acknowledgment failure prevents dispatch and returns a correlation reference.

The reward transport remains the existing sendCurrency implementation. A false or thrown result is unconfirmed, not proof that no increment occurred. Such a claim stays consumed and receives a partial audit outcome. It must not be blindly replayed or refunded; staff can inspect the correlated intent and final outcome. A completion-audit failure after successful dispatch does not report failed delivery.

This does not guarantee exactly-once emulator processing, introduce automatic reward recovery, or claim that database reservation and external dispatch are one distributed transaction. No migration or live data change is performed.

Tests exercise the real action and generated Drizzle SQL with controlled database, session, audit and currency transports. They prove boundary ordering and error mapping, not actual multi-connection MariaDB locking or emulator acceptance. The initial regression run had nine expected failures before implementation.