Brief Description
What: Consolidate and clean up the credits consumption paths so debits are performed via a single, well-defined API that guarantees atomic, race-safe behavior and consistent event emission. As part of the cleanup, improve typing, error handling and logging around credit operations and add targeted unit and integration tests (including concurrent-consumption scenarios) to validate correctness.
Why: A race in the current credits flow can allow concurrent requests to consume the same balance (double-spend), producing negative balances and inaccurate billing. Refactoring and tests will reduce production risk, restore accurate usage accounting and make the credits code easier to maintain and reason about.
Context
Current state: Credits business logic is implemented in the Credits & Usage Management area; primary logic is exercised from server actions in d/actions/credits.ts with supporting helpers in src/lib/credits-events.ts and the Prisma client in src/lib/db.ts. The database schema (prisma schema) persists user/project balances.
Gap / limitation: The existing flow allows non-atomic read-modify-write patterns and has sparse coverage for concurrent scenarios. Event emission and error paths are fragmented, making it hard to reason about failure modes and reconciliation. There are limited or no tests that simulate parallel consumption.
Dependencies & constraints: Changes must remain compatible with the payments/subscriptions and background job flows that consume credits and should avoid large schema migrations or breaking public API surfaces. The goal is a small, focused cleanup and refactor that improves safety and observability.
Resources
No additional resources.
Brief Description
What: Consolidate and clean up the credits consumption paths so debits are performed via a single, well-defined API that guarantees atomic, race-safe behavior and consistent event emission. As part of the cleanup, improve typing, error handling and logging around credit operations and add targeted unit and integration tests (including concurrent-consumption scenarios) to validate correctness.
Why: A race in the current credits flow can allow concurrent requests to consume the same balance (double-spend), producing negative balances and inaccurate billing. Refactoring and tests will reduce production risk, restore accurate usage accounting and make the credits code easier to maintain and reason about.
Context
Current state: Credits business logic is implemented in the Credits & Usage Management area; primary logic is exercised from server actions in d/actions/credits.ts with supporting helpers in src/lib/credits-events.ts and the Prisma client in src/lib/db.ts. The database schema (prisma schema) persists user/project balances.
Gap / limitation: The existing flow allows non-atomic read-modify-write patterns and has sparse coverage for concurrent scenarios. Event emission and error paths are fragmented, making it hard to reason about failure modes and reconciliation. There are limited or no tests that simulate parallel consumption.
Dependencies & constraints: Changes must remain compatible with the payments/subscriptions and background job flows that consume credits and should avoid large schema migrations or breaking public API surfaces. The goal is a small, focused cleanup and refactor that improves safety and observability.
Resources
No additional resources.