improvement(usage): bar execution if limits cannot be determined, init user stats record on user creation instead of in stripe plugin

[waleedlatif1]

Summary

bar execution if limits cannot be determined, init user stats record on user creation instead of in stripe plugin. prev, we only init the user stats record in onCustomerCreate but now we can do it in a db hook outside of the stripe plugin so even self-hosted users with no stripe initialized can meter, even though it won't be enforced.

for users who are self-hosting & do not have corresponding user_stats records for their users, it will be created when persisting the execution logs, instead of doing an insert we do an upsert

Fixes #1393

Type of Change

• Bug fix

Testing

Tested manually.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
sim	Ready	Preview	Comment	Sep 20, 2025 8:38pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Skipped			Sep 20, 2025 8:38pm

[greptile-apps]

Greptile Summary

This PR addresses a critical issue for self-hosted users by moving user stats initialization from Stripe's onCustomerCreate webhook to the Better Auth database user creation hook. The changes ensure that all users (including self-hosted ones without Stripe integration) have proper usage tracking initialized immediately upon account creation.

The key architectural change moves the handleNewUser() call from apps/sim/lib/auth.ts line 1170 (Stripe plugin) to lines 76-92 (Better Auth database hook). This allows self-hosted users without billing systems to still have usage metering, addressing the "Failed to get usage limit info" errors from issue #1393.

The PR also implements a security-first approach to usage monitoring by changing error handling from permissive to restrictive. When usage limits cannot be determined due to database errors or missing user stats records, the system now blocks execution (isExceeded: true, limit: 0) instead of allowing it to proceed. This prevents potential abuse scenarios where users could bypass usage limits during system failures.

Additionally, the error messages throughout the usage monitoring system have been enhanced to provide clearer debugging information, including specific user IDs and context about whether records are missing or improperly initialized.

Confidence score: 4/5

• This PR addresses a legitimate issue and improves system security by preventing usage limit bypasses
• The architectural change from Stripe-dependent to auth-hook initialization is sound and well-implemented
• Enhanced error handling provides better debugging while maintaining security posture through restrictive blocking

_{3 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}