Skip to content

Conversation

@whoAbhishekSah
Copy link
Member

@whoAbhishekSah whoAbhishekSah commented Feb 11, 2026

Summary

Add InputHintOption message and input_options field to PreferenceTrait for user-friendly option display.

Changes

// New message
message InputHintOption {
  string name = 1;   // Machine-readable identifier (e.g., "sq_km")
  string title = 2;  // User-friendly display (e.g., "Square Kilometers")
}

// New field in PreferenceTrait
repeated InputHintOption input_options = 28;

Usage

When input_options is provided, it takes precedence over input_hints. This allows:

  • Machine-readable values for storage/validation
  • User-friendly titles for UI display

Example:

input_options:
  - name: sq_km
    title: Square Kilometers
  - name: sq_ft
    title: Square Feet

Summary by CodeRabbit

  • New Features
    • Preference settings now support structured input options with machine-friendly IDs and user-facing titles.
    • Preferences can show a display title for selected values.
    • When structured input options are provided they take precedence over legacy input hints.

Add InputHintOption message with name and title fields for user-friendly
option display in preference traits. The input_options field in PreferenceTrait
allows specifying both machine-readable names and display titles.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@coderabbitai
Copy link

coderabbitai bot commented Feb 11, 2026

📝 Walkthrough

Walkthrough

Added a new protobuf message InputHintOption and two new fields: PreferenceTrait.input_options (repeated) which takes precedence over input_hints, and Preference.value_title populated from InputHintOption.title when input_options is configured.

Changes

Cohort / File(s) Summary
Protobuf model updates
raystack/frontier/v1beta1/models.proto
Added message InputHintOption { string name = 1; string title = 2; }. Added repeated InputHintOption input_options = 28; to PreferenceTrait (supersedes input_hints when present). Added string value_title = 8; to Preference (populated from InputHintOption.title).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐇 I nibble on proto lines so neat,
A new option sprouts, concise and sweet,
Hints step aside with courteous grace,
Titles settle gently into place,
A hop, a change — the schema's complete!

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The pull request title accurately summarizes the main change: adding InputHintOption for structured preference options.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/preference-input-options

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments
raystack/frontier/v1beta1/models.proto (1)

575-577: Consider marking value_title as OUTPUT_ONLY.

Since value_title is server-populated from InputHintOption.title (as noted in the comment), it should likely be marked with (google.api.field_behavior) = OUTPUT_ONLY to be consistent with other computed/derived fields in this file (e.g., Group.users, Project.members_count, BillingAccount.organization).

Suggested change
   // value_title is the human-readable display title for the value
   // Populated from InputHintOption.title when the trait has input_options configured
-  string value_title = 8;
+  string value_title = 8 [(google.api.field_behavior) = OUTPUT_ONLY];

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Fix all issues with AI agents
In `@raystack/frontier/v1beta1/models.proto`:
- Around line 521-527: InputHintOption allows empty/invalid identifiers; add
validation rules to ensure name is non-empty (and matches a stable
machine-readable pattern) and title is non-empty. Update the InputHintOption
message to include validation annotations (e.g., protoc-gen-validate /
validate.rules) on fields name and title: require name to be non-empty and
enforce a conservative pattern such as lowercase alphanumerics/underscores (or
your project's chosen identifier regex) and require title to be non-empty;
reference the message name InputHintOption and the fields name and title when
applying these annotations so generated code/validators will reject
empty/invalid values.
- Around line 557-560: Clarify the precedence rule for InputHintOption vs
input_hints: update the comment for the repeated field input_options to state
explicitly that input_options only takes precedence when it is present and
non-empty; if clients send input_options: [] (an empty list), the service should
fall back to using input_hints to populate options. Mention that implementations
may validate/require non-empty input_options if they want to enforce Option A,
and reference the fields InputHintOption, input_options, and input_hints in the
comment so the behavior is unambiguous.

Comment on lines +521 to +527
// InputHintOption represents a selectable option with a machine-readable name and user-friendly title
message InputHintOption {
// Machine-readable identifier (e.g., "sq_km", "megagram")
string name = 1;
// User-friendly display title (e.g., "Square Kilometers", "Megagram (Mg)")
string title = 2;
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Add validation for InputHintOption fields to avoid empty/invalid identifiers.

Empty name values undermine the “machine‑readable identifier” contract and can collide in storage/validation. Consider enforcing non‑empty (and optionally a stable pattern) for name and title.

🛡️ Suggested validation rules
 message InputHintOption {
   // Machine-readable identifier (e.g., "sq_km", "megagram")
-  string name = 1;
+  string name = 1 [(validate.rules).string = {min_len: 1, pattern: "^[A-Za-z0-9-_]+$"}];
   // User-friendly display title (e.g., "Square Kilometers", "Megagram (Mg)")
-  string title = 2;
+  string title = 2 [(validate.rules).string = {min_len: 1}];
 }
🤖 Prompt for AI Agents
In `@raystack/frontier/v1beta1/models.proto` around lines 521 - 527,
InputHintOption allows empty/invalid identifiers; add validation rules to ensure
name is non-empty (and matches a stable machine-readable pattern) and title is
non-empty. Update the InputHintOption message to include validation annotations
(e.g., protoc-gen-validate / validate.rules) on fields name and title: require
name to be non-empty and enforce a conservative pattern such as lowercase
alphanumerics/underscores (or your project's chosen identifier regex) and
require title to be non-empty; reference the message name InputHintOption and
the fields name and title when applying these annotations so generated
code/validators will reject empty/invalid values.

Comment on lines 557 to +560
InputType input_type = 27;
// Structured input options with name and title for select/combobox/multiselect inputs
// Takes precedence over input_hints when both are provided
repeated InputHintOption input_options = 28;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Make the precedence rule unambiguous when input_options is empty.

If clients send input_options: [], the current wording implies input_hints is ignored, which could yield no options. Consider enforcing non‑empty lists or explicitly stating fallback behavior.

🧭 Option A: enforce non-empty lists
-  // Takes precedence over input_hints when both are provided
-  repeated InputHintOption input_options = 28;
+  // Takes precedence over input_hints when non-empty
+  repeated InputHintOption input_options = 28 [
+    (validate.rules).repeated = {min_items: 1}
+  ];
🧭 Option B: clarify fallback in comment (if empty lists are allowed)
-  // Takes precedence over input_hints when both are provided
+  // Takes precedence over input_hints when non-empty; otherwise input_hints applies
   repeated InputHintOption input_options = 28;
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
InputType input_type = 27;
// Structured input options with name and title for select/combobox/multiselect inputs
// Takes precedence over input_hints when both are provided
repeated InputHintOption input_options = 28;
InputType input_type = 27;
// Structured input options with name and title for select/combobox/multiselect inputs
// Takes precedence over input_hints when non-empty
repeated InputHintOption input_options = 28 [
(validate.rules).repeated = {min_items: 1}
];
Suggested change
InputType input_type = 27;
// Structured input options with name and title for select/combobox/multiselect inputs
// Takes precedence over input_hints when both are provided
repeated InputHintOption input_options = 28;
InputType input_type = 27;
// Structured input options with name and title for select/combobox/multiselect inputs
// Takes precedence over input_hints when non-empty; otherwise input_hints applies
repeated InputHintOption input_options = 28;
🤖 Prompt for AI Agents
In `@raystack/frontier/v1beta1/models.proto` around lines 557 - 560, Clarify the
precedence rule for InputHintOption vs input_hints: update the comment for the
repeated field input_options to state explicitly that input_options only takes
precedence when it is present and non-empty; if clients send input_options: []
(an empty list), the service should fall back to using input_hints to populate
options. Mention that implementations may validate/require non-empty
input_options if they want to enforce Option A, and reference the fields
InputHintOption, input_options, and input_hints in the comment so the behavior
is unambiguous.

Add value_title field to show human-readable display title alongside
the machine-readable value in preference responses.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant