feat(rate-limits): make rate limits configurable via environment variables

[waleedlatif1]

Summary

Make rate limits configurable via environment variables, default values are what we had before as magic number so no need to set them anywhere

Type of Change

• New feature

Testing

N/A

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 Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sim	❌ Failed (Inspect)			Aug 7, 2025 3:56am

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
docs	⬜️ Skipped (Inspect)			Aug 7, 2025 3:56am

[greptile-apps]

Greptile Summary

This PR refactors the rate limiting system to use configurable environment variables instead of hardcoded values. The change affects the core rate limiting infrastructure by:

1. Environment Configuration: Adds 10 new environment variables in env.ts for rate limiting configuration, including window duration (RATE_LIMIT_WINDOW_MS), manual execution bypass limit (MANUAL_EXECUTION_LIMIT), and tier-specific limits for sync/async API executions across free, pro, team, and enterprise subscription plans.

2. Service Layer Updates: Modifies the RateLimiter service to consume these environment variables through the types.ts module, replacing hardcoded values like 60000 (1 minute window) and 999999 (manual execution limit) with configurable constants.

3. Test Alignment: Updates the test suite to use the new MANUAL_EXECUTION_LIMIT constant instead of hardcoded expectations, ensuring tests validate actual runtime behavior.

4. Deployment Configuration: Updates the Helm chart's values.yaml to include the new environment variables with sensible defaults that maintain existing behavior.

This change integrates well with the existing environment management system that uses @t3-oss/env-nextjs and Zod validation. The rate limiting system follows a tiered subscription model where higher-paying customers get increased API execution limits, with separate controls for synchronous and asynchronous operations. The implementation maintains backward compatibility through default values while enabling operational flexibility for different deployment environments.

Confidence score: 5/5

• This PR is safe to merge with minimal risk as it maintains existing behavior through sensible defaults
• Score reflects well-structured changes that follow established patterns and maintain backward compatibility
• No files require special attention as all changes are straightforward configuration updates

_{5 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}