Fix free limits and email notifications for inactive users

[KMKoushik]

When a user's subscription is inactive, they should be treated as a FREE plan user with all free tier limits applied and appropriate email notifications.

Changes:

• limit-service.ts: Use getActivePlan() for daily limit checks so inactive users get FREE plan daily limits (100/day) instead of unlimited
• team-service.ts: Fix isPaidPlan flag in email notifications to check team.isActive, ensuring inactive users receive free plan messaging

This ensures:

1. Inactive users have daily limits enforced (100 emails/day)
2. Inactive users receive correct email messaging (upgrade plan vs verify team)
3. All free tier limits apply when subscription is inactive

🤖 Generated with Claude Code

---

Summary by cubic

Treat inactive subscriptions as FREE plan users across limits and emails. Enforces 100 emails/day and sends the correct free-plan messaging.

• Bug Fixes
  • Use getActivePlan for daily limit checks so inactive users get the FREE limit (100/day).
  • Email notifications now consider team.isActive when setting isPaidPlan, sending free-plan upgrade messages to inactive teams.

Summary by CodeRabbit

• Bug Fixes
  • Improved email sending limits to properly account for active subscription status. Teams with inactive subscriptions now correctly receive free-tier email limits as intended.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
unsend-marketing	Ready	Preview	Comment	Oct 25, 2025 8:20pm

[coderabbitai]

Walkthrough

This pull request modifies limit calculation logic across two service files. In limit-service.ts, the daily email limit determination now uses an getActivePlan() function to compute the active plan status, replacing a direct plan comparison. The logic treats inactive or FREE plans by applying the FREE tier email limit. In team-service.ts, the paid-plan determination adds an additional check for team.isActive alongside the existing plan check, affecting limit notifications and related messaging throughout the codebase.

Possibly related PRs

• fix: do not limit users when self-hosting #225: Modifies team limit logic and reorganizes interactions between team-service and LimitService for member limit delegation.
• Configure Email Usage Alert Logic #278: Updates email limit and alert logic to treat inactive subscriptions equivalently to FREE plans using isActive and getActivePlan.
• block sending emails on limits #216: Updates the same core service files to refactor how plan status and isActive are determined for email limits and notifications.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Fix free limits and email notifications for inactive users" directly aligns with the main changes across both modified files. The title clearly captures the core objective: ensuring inactive subscriptions are treated as FREE plan users with appropriate daily limits (100 emails/day) and correct email messaging. The title is concise, specific, and avoids vague or generic phrasing. A teammate scanning the git history would immediately understand that this PR addresses how inactive users are handled with free-tier restrictions.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch claude/apply-free-limits-email-011CUUXF2krtrPswNnvXp2P1

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cubic-dev-ai]

No issues found across 2 files

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/web/src/server/service/team-service.ts (1)

577-577: Fix inconsistent isPaidPlan logic.

This line doesn't check team.isActive, which is inconsistent with the updated logic in Lines 404 and 506. This will cause incorrect email content for inactive subscriptions.

Apply this diff to align with the updated logic:

-  const isPaidPlan = team.plan !== "FREE";
+  const isPaidPlan = team.isActive && team.plan !== "FREE";

🧹 Nitpick comments (1)

apps/web/src/server/service/limit-service.ts (1)

15-17: Good helper function, but consider extracting to a shared utility.

The getActivePlan function correctly determines the effective plan for a team. However, this logic is duplicated inline in team-service.ts (Lines 404 and 506). Consider extracting this to a shared utility module to ensure consistency and avoid duplication.

For example, create a shared helper:

// apps/web/src/lib/utils/team-utils.ts
import { Plan } from "@prisma/client";

export function getActivePlan(team: { plan: Plan; isActive: boolean }): Plan {
  return team.isActive ? team.plan : "FREE";
}

Then import and use it in both limit-service.ts and team-service.ts.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8e569f8 and 7ce935d.

📒 Files selected for processing (2)

• apps/web/src/server/service/limit-service.ts (1 hunks)
• apps/web/src/server/service/team-service.ts (2 hunks)

🧰 Additional context used

📓 Path-based instructions (4)

**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

Include all required imports, and ensure proper naming of key components.

Files:

• apps/web/src/server/service/limit-service.ts
• apps/web/src/server/service/team-service.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{ts,tsx}: TypeScript-first: use .ts/.tsx for source code (avoid JavaScript source files)
Use 2-space indentation and semicolons (Prettier 3 enforces these)
Adhere to @usesend/eslint-config; fix all ESLint warnings (CI fails on warnings)
Do not use dynamic imports; always place imports at the top of the module

Files:

• apps/web/src/server/service/limit-service.ts
• apps/web/src/server/service/team-service.ts

**/*.{ts,tsx,md}

📄 CodeRabbit inference engine (AGENTS.md)

Format code with Prettier 3 (run pnpm format)

Files:

• apps/web/src/server/service/limit-service.ts
• apps/web/src/server/service/team-service.ts

apps/web/**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

apps/web/**/*.{ts,tsx}: In apps/web, use the / alias for src imports (e.g., import { x } from "/utils/x")
Prefer using tRPC in apps/web unless explicitly asked otherwise

Files:

• apps/web/src/server/service/limit-service.ts
• apps/web/src/server/service/team-service.ts

🧬 Code graph analysis (1)

apps/web/src/server/service/limit-service.ts (1)

apps/web/src/lib/constants/plans.ts (1)

• PLAN_LIMITS (12-36)

🔇 Additional comments (3)

apps/web/src/server/service/team-service.ts (2)

403-404: LGTM! Correct logic for inactive subscriptions.

The addition of the team.isActive check ensures that inactive subscriptions are correctly treated as FREE plan users, which aligns with the PR objectives.

---

505-506: LGTM! Consistent with maybeNotifyEmailLimitReached.

The logic correctly mirrors the change in maybeNotifyEmailLimitReached, ensuring consistent email messaging across warning and limit-reached notifications.

apps/web/src/server/service/limit-service.ts (1)

139-143: LGTM! Correctly enforces FREE plan limits for inactive subscriptions.

The use of getActivePlan ensures that inactive users receive the FREE plan daily limit (100 emails/day) instead of their configured dailyEmailLimit, which aligns perfectly with the PR objectives.