feat(paykit): add custom plan and meter intervals#118
Open
t3duk wants to merge 7 commits intogetpaykit:mainfrom
Open
feat(paykit): add custom plan and meter intervals#118t3duk wants to merge 7 commits intogetpaykit:mainfrom
t3duk wants to merge 7 commits intogetpaykit:mainfrom
Conversation
|
@t3duk is attempting to deploy a commit to the maxktz Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughIntroduced a centralized Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Contributor
Author
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
packages/paykit/src/types/interval.ts (1)
103-116: Keep Stripe translation next to the Stripe adapter.The rest of this module is provider-agnostic, but
getStripeRecurringIntervalbakes Stripe semantics intosrc/types. Moving this helper besidepackages/paykit/src/providers/stripe.tswill make additional providers easier to support without growing the core interval module around Stripe-specific behavior.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/paykit/src/types/interval.ts` around lines 103 - 116, The helper getStripeRecurringInterval embeds Stripe-specific semantics inside the provider-agnostic interval module; move this function out of packages/paykit/src/types/interval.ts into the Stripe adapter file (where the Stripe provider is implemented, e.g., next to the Stripe adapter in packages/paykit/src/providers/stripe.ts) and update imports: remove getStripeRecurringInterval from the interval module, export it or define it locally in the Stripe adapter (keeping the same signature) and adjust any call sites to import it from the Stripe provider module instead so core types remain provider-agnostic.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/paykit/src/entitlement/entitlement.service.ts`:
- Around line 35-36: The current catch-up loop that repeatedly calls
addInterval(nextResetAt, resetInterval) until nextResetAt > now is O(N) for
small second-based resetInterval; replace it with an O(1) fast-forward: compute
the number of missed intervals as Math.max(0, Math.ceil((now - nextResetAt) /
resetInterval)) (guarding that resetInterval > 0) and advance nextResetAt by
missedIntervals * resetInterval in one step instead of looping; update the code
paths that reference nextResetAt and addInterval (the while loop and any
subsequent logic in the entitlement reset handling) to use this computed
fast-forwarded nextResetAt.
In `@packages/paykit/src/types/interval.ts`:
- Around line 15-18: The schema currently only accepts numeric seconds but your
serializer (serializeMeteredResetInterval) emits numeric intervals as strings,
so validate both forms by updating meteredResetIntervalSchema to accept either
the enum values or a coerced/parsed positive integer; for example replace the
z.number().int().positive(...) branch with z.coerce.number().int().positive(...)
(or use z.string().regex(/^\d+$/).transform(s=>parseInt(s,10))) so a serialized
"90" will validate and round-trip against meteredResetIntervalSchema while
keeping meteredResetIntervalValues unchanged.
---
Nitpick comments:
In `@packages/paykit/src/types/interval.ts`:
- Around line 103-116: The helper getStripeRecurringInterval embeds
Stripe-specific semantics inside the provider-agnostic interval module; move
this function out of packages/paykit/src/types/interval.ts into the Stripe
adapter file (where the Stripe provider is implemented, e.g., next to the Stripe
adapter in packages/paykit/src/providers/stripe.ts) and update imports: remove
getStripeRecurringInterval from the interval module, export it or define it
locally in the Stripe adapter (keeping the same signature) and adjust any call
sites to import it from the Stripe provider module instead so core types remain
provider-agnostic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 4c457a1e-0296-4163-a4d0-8ebec58e2c00
📒 Files selected for processing (10)
packages/paykit/src/cli/utils/format.tspackages/paykit/src/entitlement/entitlement.service.tspackages/paykit/src/product/product-sync.service.tspackages/paykit/src/product/product.service.tspackages/paykit/src/providers/stripe.tspackages/paykit/src/subscription/subscription.service.tspackages/paykit/src/types/__tests__/interval.test.tspackages/paykit/src/types/interval.tspackages/paykit/src/types/product.tspackages/paykit/src/types/schema.ts
for stuff like months, years etc, it isn't fixed, and will vary, therfore we use the while loop. but for fixed intervals we can use a calculation which is o(1) to fast track this
Contributor
Author
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
landing/content/docs/flows/metered-usage.mdx (1)
60-60: Include theburstexample in the explanatory sentence for consistency.The paragraph mentions only Free/Pro after adding
burst, which can feel inconsistent with the snippet.✏️ Suggested docs tweak
-Free customers get 100 messages per month; Pro customers get 2,000. Custom second-based resets are useful for short-lived buckets like hourly quotas, while named resets cover common billing cadences such as `biweek` or `quarterly`. +Free customers get 100 messages per month; Pro customers get 2,000. The Burst add-on shows a short reset window (`3_600` seconds) for hourly quotas, while named resets cover common cadences such as `biweek` or `quarterly`.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@landing/content/docs/flows/metered-usage.mdx` at line 60, Update the explanatory sentence that currently lists only Free and Pro customers to also mention the newly added "burst" plan for consistency with the snippet; find the paragraph that begins "Free customers get 100 messages per month; Pro customers get 2,000." and change it to include "burst" (and its quota) alongside Free and Pro, and ensure the sentence still explains that custom second-based resets are for short-lived buckets and named resets cover cadences like `biweek` or `quarterly`.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@landing/content/docs/concepts/plans-and-features.mdx`:
- Line 133: The bullet for `interval` in plans-and-features.mdx is a fragment;
change it to a complete sentence such as "The `interval` can be `day`, `week`,
`month`, `quarterly`, `biyear`, or `year`." Locate the existing line referencing
`interval` and replace the fragment with this full-sentence wording so the docs
read clearly and consistently.
---
Nitpick comments:
In `@landing/content/docs/flows/metered-usage.mdx`:
- Line 60: Update the explanatory sentence that currently lists only Free and
Pro customers to also mention the newly added "burst" plan for consistency with
the snippet; find the paragraph that begins "Free customers get 100 messages per
month; Pro customers get 2,000." and change it to include "burst" (and its
quota) alongside Free and Pro, and ensure the sentence still explains that
custom second-based resets are for short-lived buckets and named resets cover
cadences like `biweek` or `quarterly`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 07c96f62-5125-4cf3-925f-9cccc518116d
📒 Files selected for processing (5)
landing/content/docs/concepts/entitlements.mdxlanding/content/docs/concepts/plans-and-features.mdxlanding/content/docs/flows/metered-usage.mdxlanding/content/docs/flows/subscription-billing.mdxlanding/content/docs/get-started/installation.mdx
✅ Files skipped from review due to trivial changes (2)
- landing/content/docs/get-started/installation.mdx
- landing/content/docs/concepts/entitlements.mdx
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR addresses the limited intervals allowed on a plan price and feature limit reset.
Summary
Todo
Let me know if any of my implementation looks wrong, or if we don't want to move in this direction.
Summary by CodeRabbit
New Features
Improvements
Tests
Documentation