feat(frontier)!: move CreatePlan and UpdatePlan to AdminService and add ListAllPlans - #496
feat(frontier)!: move CreatePlan and UpdatePlan to AdminService and add ListAllPlans#496rohilsurana wants to merge 2 commits into
Conversation
|
The latest Buf updates on your PR. Results from workflow Validate / validate (pull_request).
|
51559d3 to
ae6d5a6
Compare
|
Warning Review limit reached
Next review available in: 42 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe protobuf contract moves plan creation and update operations from Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
raystack/frontier/v1beta1/admin.proto (2)
441-444: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winRestrict
stateto known values.The comment documents that valid values are "active" or "disabled", or empty for all plans. The field has no validation enforcing this. An unrecognized value silently returns an empty result instead of surfacing an error. Add a
buf.validate.fieldconstraint, similar to theintervalfield onPlanRequestBody.♻️ Proposed validation
message ListAllPlansRequest { // filter by plan state, e.g. "active" or "disabled". an empty value returns all plans - string state = 1; + string state = 1 [(buf.validate.field).string = { + in: [ + "", + "active", + "disabled" + ] + }]; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@raystack/frontier/v1beta1/admin.proto` around lines 441 - 444, Update ListAllPlansRequest.state with a buf.validate.field string constraint limiting values to "active", "disabled", or the empty string, following the validation pattern used by PlanRequestBody.interval. Preserve empty state as the request for all plans and reject unrecognized values during validation.
450-471: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winApply the same validation rigor to
state,on_start_credits, andtrial_days.
interval(line 457) restricts input to a known set of values, butstate(line 468) accepts any string with no constraint, so it has the same silent-mismatch risk asListAllPlansRequest.state. Additionally,on_start_creditsandtrial_days(lines 465-466) accept negativeint64values with no lower-bound check, even though negative credits or negative trial days are not meaningful business values.♻️ Proposed validation
int64 on_start_credits = 6; - int64 trial_days = 7; + int64 trial_days = 7 [(buf.validate.field).int64.gte = 0]; - string state = 8; + string state = 8 [(buf.validate.field).string = { + in: [ + "active", + "disabled" + ] + }];🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@raystack/frontier/v1beta1/admin.proto` around lines 450 - 471, Update PlanRequestBody fields state, on_start_credits, and trial_days to add validation consistent with the existing request validation: constrain state to the supported plan-state values using the established state validation, and require on_start_credits and trial_days to be non-negative. Keep the existing field types and interval validation unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@raystack/frontier/v1beta1/admin.proto`:
- Around line 441-444: Update ListAllPlansRequest.state with a
buf.validate.field string constraint limiting values to "active", "disabled", or
the empty string, following the validation pattern used by
PlanRequestBody.interval. Preserve empty state as the request for all plans and
reject unrecognized values during validation.
- Around line 450-471: Update PlanRequestBody fields state, on_start_credits,
and trial_days to add validation consistent with the existing request
validation: constrain state to the supported plan-state values using the
established state validation, and require on_start_credits and trial_days to be
non-negative. Keep the existing field types and interval validation unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 2b2e103a-8583-4771-80ec-ad38b1912a78
📒 Files selected for processing (2)
raystack/frontier/v1beta1/admin.protoraystack/frontier/v1beta1/frontier.proto
💤 Files with no reviewable changes (1)
- raystack/frontier/v1beta1/frontier.proto
|
Applied both validation nits in fc68fa3: |
2 participants
What
Move the plan write APIs to
AdminServiceand add a newListAllPlansAPI.CreatePlanandUpdatePlanmove fromFrontierServicetoAdminService.ListAllPlansonAdminService. It returns every plan, including disabled ones.ListPlansandGetPlanstay onFrontierServiceand are unchanged.ListPlansstill returns active plans only.The request and response messages for
CreatePlanandUpdatePlanstay infrontier.protoand are reused by the admin RPCs, soadmin.protonow importsfrontier.proto.Why
Plan writes are admin only. Today they sit on
FrontierServiceand are gated to platform superusers by the server. Moving them toAdminServiceputs them on the admin surface where they belong.The billing reconcile flow in Frontier needs to read every plan for export, including disabled ones.
ListPlansreturns active plans only, so it cannot see a disabled plan.ListAllPlansfills that gap.Breaking change
CreatePlanandUpdatePlanare removed fromFrontierService. Any client that calls them there must switch toAdminService.buf breakingstill passes because proton checks at the WIRE level, and moving an RPC does not break the wire format of the messages. In Frontier, the e2e billing tests callFrontierService.CreatePlantoday and will move to the admin client in the follow up.Follow up in Frontier
CreatePlan,UpdatePlan, andListAllPlanshandlers on the admin service.ListAllPlansfor export.