cameri / nostream / 41232579328

77%

push

github

feat(payments): add per-plan event rate limits and retention (#922)



## 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.

... (continued)

4384 of 6201 branches covered (70.7%)

Branch coverage included in aggregate %.

66 of 66 new or added lines in 3 files covered. (100.0%)

9554 of 11817 relevant lines covered (80.85%)

775.24 hits per line