[Priyanshubhartistm]

Description

Builds on the subscription lifecycle (#909). Nothing changes unless payments.enabled is true and a plan sets limits.rateLimits or limits.retentionMaxDays (settings and validation already exist from #849).

• Rate limits: EventMessageHandler.isRateLimited uses the limits of the sender's plan in place of limits.event.rateLimits while the subscription gives access (grace included). An empty list means no limit. Everyone else, and a subscriber whose subscription ended or whose plan was removed from the settings, keeps the global limits. Counters are keyed exactly as before (<pubkey>:events:<period>), whitelists still apply.
• The plan comes from the admission cache: it is cached under <pubkey>:subscription-plan (plan:<id> or none) with a TTL that never outlives access, and isUserAdmitted fills it when it reads the subscription, so there is no extra database read per event. If a read fails the global limits apply and nothing is cached.
• Retention: the purge (deleteExpiredAndRetained) takes planRetention. Events of subscribers on a plan with retentionMaxDays are purged at the plan's window, everyone else at the global one, with the kind and pubkey whitelists unchanged. A subscriber counts only while their access lasts, so once it ends their events fall back to the global window at the next pass. The query is the same as before when no plan sets a retention.
• CONFIGURATION.md describes both settings.

Related Issue

Closes #921

Motivation and Context

Rate limits and retention were global, so a premium subscriber got the same limits as everyone else. This is the "higher tiers get better rate limits and longer event retention" part of the tiered access.

A plan retention only applies while limits.event.retention.maxDays is set (the purge does not run without it). Per-plan connection and subscription-count limits are not part of this PR.

How Has This Been Tested?

• New unit tests: the plan limits in isRateLimited (plan vs global, empty list, kinds, expired, lapsed and grace, removed plan, whitelist, subscriptions off, cache hit/miss/error/TTL, database error), the plan cached by isUserAdmitted, the purge query with plan retention (exact SQL, whitelists, several plans, shorter windows, expired subscribers, invalid values) and MaintenanceService. Reverting the access check, the cache read, the global exclusion, the expired filter or the subscriptions-enabled check each fails a test.
• Ran the purge on a real PostgreSQL 16 with the migrations applied (global 7 days, premium 90 days): an active premium subscriber and one in grace keep their 3 and 20 day old events and lose the 100 and 400 day old ones; an expired premium subscriber and a user without a plan keep only the 3 day old ones.
• pnpm lint, pnpm check:deps, pnpm run build:check, pnpm run build, pnpm run verify:cli:build, pnpm run test:unit (2547 passing), pnpm run test:cli (105 passing).

[changeset-bot]

🦋 Changeset detected

Latest commit: d29dd62

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
nostream	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coveralls]

Coverage Report for CI Build 41232122419

Coverage increased (+0.1%) to 77.356%

Details

• Coverage increased (+0.1%) from the base build.
• Patch coverage: 66 of 66 lines across 3 files are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	11817
Covered Lines:	9554
Line Coverage:	80.85%
Relevant Branches:	6201
Covered Branches:	4384
Branch Coverage:	70.7%
Branches in Coverage %:	Yes
Coverage Strength:	776.54 hits per line

---

💛 - Coveralls

[greptile-apps]

Confidence Score: 5/5

[High impact] The PR appears safe to merge; no actionable issues remain.

Summary

Adds event rate limits and retention windows for subscription plans.

• Subscribers can publish under their plan’s event rate limits.
• Event cleanup now uses each active plan’s retention window.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Incoming event] --> B{Plan defines rate limits?}
  B -->|Yes| C[Read cached plan or subscription]
  C --> D{Subscription gives access?}
  D -->|Yes| E[Apply plan limits]
  D -->|No| F[Apply global limits]
  B -->|No| F
  E --> G[Continue admission checks]
  F --> G
  H[Retention purge] --> I{Subscriber has access and plan retention?}
  I -->|Yes| J[Use plan window]
  I -->|No| K[Use global window]
  J --> L[Keep whitelisted events]
  K --> L

Loading

_{Reviews (5) · Last reviewed commit: "Merge branch 'main' into feat/subscripti..." · Reviewed by Greptile}