[Bug]:Title Users can use more credits than allotted

[kstij1]

Summary

Users are able to consume more credits than their allocated/available balance. The system allows overage beyond the allotted limit instead of preventing the action or failing fast.

Steps to reproduce

1. Allocate a user a small number of credits (e.g., 20).
2. Execute actions that consume credits until reaching the limit (e.g., chats, document processing, model runs).
3. Continue executing actions beyond the limit.
4. Observe that usage continues and the balance shows negative or exceeds the allocation.

Expected behavior

• The system enforces a strict hard cap: when remaining credits ≤ 0, any further credit-consuming operation is rejected with a clear error and no credits are deducted.
• UI controls should also block or warn, but server must be the source of truth and enforce limits.

Actual behavior

• Operations continue beyond allocation; resulting values exceed the allowed balance.
• In some cases, UI displays over-limit values (e.g., 27/20 used) without an error.

Environment

• OS: macOS 13 (Ventura)
• Browser: Chrome 128
• App/Backend branch: main (latest)
• Workspace with multiple members

Additional context

Likely causes:

• Limit checks only on client, not on server.
• Race conditions around concurrent requests; missing transactional check on remaining balance.
• Usage write occurs before validation, or validation uses stale cached totals.
• Background/queued jobs bypass the normal guard.

[ikeshav26]

Summary

Users are able to consume more credits than their allocated/available balance. The system allows overage beyond the allotted limit instead of preventing the action or failing fast.

Steps to reproduce

1. Allocate a user a small number of credits (e.g., 20).
2. Execute actions that consume credits until reaching the limit (e.g., chats, document processing, model runs).
3. Continue executing actions beyond the limit.
4. Observe that usage continues and the balance shows negative or exceeds the allocation.

Expected behavior

• The system enforces a strict hard cap: when remaining credits ≤ 0, any further credit-consuming operation is rejected with a clear error and no credits are deducted.
• UI controls should also block or warn, but server must be the source of truth and enforce limits.

Actual behavior

• Operations continue beyond allocation; resulting values exceed the allowed balance.
• In some cases, UI displays over-limit values (e.g., 27/20 used) without an error.

Environment

• OS: macOS 13 (Ventura)
• Browser: Chrome 128
• App/Backend branch: main (latest)
• Workspace with multiple members

Additional context

Likely causes:

• Limit checks only on client, not on server.
• Race conditions around concurrent requests; missing transactional check on remaining balance.
• Usage write occurs before validation, or validation uses stale cached totals.
• Background/queued jobs bypass the normal guard.

@kstij1 anybody working on this??

[kstij1]

Nice work on picking this up, @ikeshav26 , your approach looks clean.

Assigning this issue to you.

Before diving in, make sure to go through the related code to stay aligned with existing logic and follow our standard practices.
Lastly, keep your commits clean and scoped properly so they don’t conflict with the existing codebase. Let’s keep it tidy

[ikeshav26]

Nice work on picking this up, @ikeshav26 , your approach looks clean.

Assigning this issue to you.

Before diving in, make sure to go through the related code to stay aligned with existing logic and follow our standard practices. Lastly, keep your commits clean and scoped properly so they don’t conflict with the existing codebase. Let’s keep it tidy

@kstij1 sure!! .... btw i aso want to work to add oauth features so that user can login or register using their google and github