Open
Conversation
📝 WalkthroughWalkthroughAdds a Personal Access Token flow to Frontier: a new RPC Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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.
Actionable comments posted: 3
🧹 Nitpick comments (2)
raystack/frontier/v1beta1/frontier.proto (1)
4264-4268:namehas only a length floor; no pattern constraint for a machine-friendly identifier.The inline comment says this is a "Machine-friendly identifier, unique per user per org", yet the only validation is
min_len = 1, which permits arbitrary whitespace, special characters, and single-character names. Every comparablenamefield for machine identifiers in this codebase enforces a pattern (e.g.,^[A-Za-z0-9-_]+$forUser,Group,Organization, etc.).✏️ Suggested constraint
string name = 1 [ - (validate.rules).string.min_len = 1, + (validate.rules).string = { + min_len: 2, + pattern: "^[A-Za-z0-9-_]+$" + }, (google.api.field_behavior) = REQUIRED ];🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@raystack/frontier/v1beta1/frontier.proto` around lines 4264 - 4268, The `name` field in frontier.proto currently only enforces min_len and should also include a pattern to restrict it to machine-friendly characters; update the `name` field's validation (the same field named "name" in frontier.proto) to add a regex constraint such as `^[A-Za-z0-9-_]+$` (while keeping or adjusting min_len as needed) so it matches other machine identifier fields in the codebase; ensure the `(validate.rules).string.pattern` is added alongside the existing `(validate.rules).string.min_len` and keep the `(google.api.field_behavior) = REQUIRED` intact.raystack/frontier/v1beta1/models.proto (1)
443-444: Consider adding an OpenAPI description and validation hint forname.The
namefield (field 2) has noopenapiv2_fielddescription or validation annotation, unlike comparablenamefields across every other model in this file (e.g.,User.name,Group.name). API consumers won't know what format/constraints to expect.✏️ Suggested addition
- string name = 2; + string name = 2 [(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = { + description: "Machine-friendly identifier for the token. Must be unique per user per organization.", + example: "\"my-ci-token\"" + }];🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@raystack/frontier/v1beta1/models.proto` around lines 443 - 444, Add an OpenAPI description and validation hint for the message's `name` field (field 2) similar to other models like `User.name` and `Group.name`: update the `name` field to include an openapiv2_field description explaining expected format (e.g., display name, allowed chars/length) and add proto validation rules (e.g., non-empty, max length, and optional pattern) so API consumers know constraints; target the `name` field (field number 2) and mirror the same description and validate.rules options used by `User.name`/`Group.name`.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@raystack/frontier/v1beta1/frontier.proto`:
- Line 4278: The repeated field project_ids currently accepts arbitrary strings;
add the same UUID validation used elsewhere by attaching a validate.rules option
to project_ids (e.g., on the repeated string field declaration for project_ids)
so each item is required to be a UUID; update the field definition for
project_ids to include (validate.rules).string.uuid = true for each element to
ensure boundary validation consistent with org_id and other ID fields.
- Around line 4275-4276: The repeated field roles (repeated string roles = 4) is
annotated as (google.api.field_behavior) = REQUIRED but that does not enforce a
non-empty list at runtime; update the field to add a validator rule by adding
(validate.rules).repeated = { min_items: 1 } to the roles field so the proto
validator enforces at least one role (mirror the user_ids validation pattern
used in CreateOrganizationInvitationRequest).
- Around line 1891-1892: CreateCurrentUserPersonalToken is missing the
grpc-gateway HTTP binding and openapiv2_operation annotations, so add a
google.api.http POST binding and an openapiv2_operation block analogous to other
CurrentUser RPCs (e.g., use POST "/v1beta1/users/me/personal_tokens" with body
"*" or the appropriate request field) and include openapiv2_operation with
operation_id "CreateCurrentUserPersonalToken" plus a short summary/description;
update the RPC declaration for CreateCurrentUserPersonalToken to include these
annotations so it is reachable via REST and appears in the OpenAPI spec.
---
Nitpick comments:
In `@raystack/frontier/v1beta1/frontier.proto`:
- Around line 4264-4268: The `name` field in frontier.proto currently only
enforces min_len and should also include a pattern to restrict it to
machine-friendly characters; update the `name` field's validation (the same
field named "name" in frontier.proto) to add a regex constraint such as
`^[A-Za-z0-9-_]+$` (while keeping or adjusting min_len as needed) so it matches
other machine identifier fields in the codebase; ensure the
`(validate.rules).string.pattern` is added alongside the existing
`(validate.rules).string.min_len` and keep the `(google.api.field_behavior) =
REQUIRED` intact.
In `@raystack/frontier/v1beta1/models.proto`:
- Around line 443-444: Add an OpenAPI description and validation hint for the
message's `name` field (field 2) similar to other models like `User.name` and
`Group.name`: update the `name` field to include an openapiv2_field description
explaining expected format (e.g., display name, allowed chars/length) and add
proto validation rules (e.g., non-empty, max length, and optional pattern) so
API consumers know constraints; target the `name` field (field number 2) and
mirror the same description and validate.rules options used by
`User.name`/`Group.name`.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
raystack/frontier/v1beta1/models.proto (1)
442-466: Consider addingreservedfor intentionally skipped field numbers.The message has deliberate gaps — 3-4 (between
titleandtoken), 6-9 (betweentokenandexpires_at), and 13-19 (betweencreated_atandmetadata) — with noreservedstatement to document them. Withoutreserved, future contributors can silently reuse those numbers, causing silent wire-format collisions with any data serialized against later versions of this message.♻️ Proposed addition
message PersonalAccessToken { string id = 1; string title = 2; + + reserved 3, 4; + // token will only be returned once as part of the create process // this value is never persisted in the system so if lost, can't be recovered string token = 5 [(google.api.field_behavior) = OUTPUT_ONLY]; + + reserved 6 to 9; google.protobuf.Timestamp expires_at = 10 [...]; google.protobuf.Timestamp last_used_at = 11 [...]; google.protobuf.Timestamp created_at = 12 [...]; + + reserved 13 to 19; google.protobuf.Struct metadata = 20; }The rest of the message — the
OUTPUT_ONLYannotation ontoken, theexpires_at/last_used_at/created_atgrouping, andmetadata = 20— all follow established file conventions and look correct.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@raystack/frontier/v1beta1/models.proto` around lines 442 - 466, The PersonalAccessToken message is missing reserved declarations for the intentionally skipped field numbers; add a reserved statement in the PersonalAccessToken message reserving the numeric ranges 3 to 4, 6 to 9, and 13 to 19 (e.g., reserved 3 to 4, 6 to 9, 13 to 19;) so future changes cannot reuse those tags and cause wire-format collisions; place this reserved line near the top of the message alongside the field declarations for clarity.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@raystack/frontier/v1beta1/models.proto`:
- Around line 442-466: The PersonalAccessToken message is missing reserved
declarations for the intentionally skipped field numbers; add a reserved
statement in the PersonalAccessToken message reserving the numeric ranges 3 to
4, 6 to 9, and 13 to 19 (e.g., reserved 3 to 4, 6 to 9, 13 to 19;) so future
changes cannot reuse those tags and cause wire-format collisions; place this
reserved line near the top of the message alongside the field declarations for
clarity.
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.
Summary by CodeRabbit