Skip to content

Conversation

@tisnik
Copy link
Contributor

@tisnik tisnik commented Aug 6, 2025

Description

LCORE-390: description for all QueryRequest fields

Type of change

  • Refactor
  • New feature
  • Bug fix
  • CVE fix
  • Optimization
  • Documentation Update
  • Configuration Update
  • Bump-up service version
  • Bump-up dependent library
  • Bump-up library or tool used for development (does not change the final image)
  • CI configuration change
  • Konflux configuration change
  • Unit tests improvement
  • Integration tests improvement
  • End to end tests improvement

Related Tickets & Documents

  • Related Issue #LCORE-390

Summary by CodeRabbit

  • Documentation
    • Enhanced API documentation for the QueryRequest model by adding detailed descriptions and usage examples for all fields, improving clarity for end-users and developers. No changes to functionality or data structure.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Aug 6, 2025

Walkthrough

Descriptive metadata and example values were added to the QueryRequest model fields in both the codebase and documentation. These enhancements affect the OpenAPI schema, Markdown documentation, and Pydantic model, providing clear descriptions and usage examples for each property without altering their types or validation logic.

Changes

Cohort / File(s) Change Summary
OpenAPI Schema Documentation
docs/openapi.json
Added descriptions and examples to all QueryRequest properties in the OpenAPI schema, clarifying their purpose and usage.
Markdown Documentation
docs/openapi.md, docs/output.md
Updated documentation for QueryRequest fields to include descriptive text for each property, specifying their intent and optionality.
Pydantic Model Enhancements
src/models/requests.py
Replaced basic type annotations with Pydantic Field definitions for all QueryRequest fields, adding descriptions and examples for improved schema documentation.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant API
    participant QueryRequest Model

    Client->>API: Sends request with QueryRequest payload
    API->>QueryRequest Model: Validates and parses fields (with new descriptions/examples)
    QueryRequest Model-->>API: Returns validated data
    API-->>Client: Responds (no change in logic, improved docs)
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~7 minutes

Possibly related PRs

Poem

🐇
With fields described and examples clear,
Our docs now shine from front to rear.
Queries, prompts, attachments too—
Each with guidance, fresh and new!
A hop, a skip, with docs so bright,
Reviewing this will be a delight!

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@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: 3

🧹 Nitpick comments (7)
src/models/requests.py (4)

99-110: Consider narrowing provider / model to an Enum or Literal

Both fields currently accept arbitrary strings, but only a finite list is actually supported.
Using Literal["openai", "watsonx", …] or a dedicated Provider(str, Enum) would give callers instant feedback and improve OpenAPI clarity.


117-137: Attachments list lacks upper bound & per-item size checks

An unbounded list (or huge content field) can easily exhaust memory or hit upstream limits.
At minimum, cap the list length with conlist(Attachment, max_items=N) and consider restricting content length in Attachment.


139-143: no_tools should be a plain bool

Because the default is False, allowing null adds an unnecessary third state.
Changing to no_tools: bool = Field(False, …) simplifies validation and generated docs.


147-151: Clarify media_type deprecation status

The comment says the value is ignored; consider

  1. Marking it as Deprecated in the description, and
  2. Rejecting non-None values via validation unless explicit compatibility mode is enabled.

This prevents silent acceptance of stale clients.

docs/output.md (1)

722-730: Type column left blank in generated table

conversation_id, provider, model, etc., show an empty “Type” which degrades readability of the Markdown docs.
If the generator cannot infer Optionals, manually force string in the schema or add type: string overrides.

docs/openapi.json (2)

1405-1540: Generated OpenAPI artefact should not be committed – prefer build-time generation instead

docs/openapi.json looks like a FastAPI/Pydantic autogenerated dump. Committing this 4 000-line artefact makes every doc-only change explode into a huge diff, invites merge conflicts and risks the file getting out-of-sync with the source models.
Consider:

# .gitignore (excerpt)
+docs/openapi.json

and regenerate the schema during CI/CD or a make docs step (e.g. python -m lightspeed_core.generate_openapi > docs/openapi.json).

This keeps the repository slim and the review surface focused on the actual source of truth (the Pydantic model with the new Field(..., description=..., examples=...) calls).


1424-1428: Nit: use “ID” (all caps) for the abbreviation

In several other schemas the term is written “Conversation ID”, while here it is Conversation Id. Aligning the capitalization improves consistency across the API:

- "title": "Conversation Id",
+ "title": "Conversation ID",

Same for the description string a few lines below.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b5afee1 and 829f97f.

📒 Files selected for processing (4)
  • docs/openapi.json (8 hunks)
  • docs/openapi.md (1 hunks)
  • docs/output.md (1 hunks)
  • src/models/requests.py (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: build-pr
  • GitHub Check: e2e_tests
🔇 Additional comments (1)
docs/openapi.md (1)

740-747: Same missing type information as in output.md

The OpenAPI-flavoured Markdown lists blank types for several QueryRequest fields.
Confirm the JSON schema contains correct type: string and update the doc generator if necessary.

Comment on lines +88 to +92
query: str = Field(
description="The query string",
examples=["What is Kubernetes?"],
)

Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Enforce non-empty query and document the requirement

query is the only mandatory input, yet an empty string would pass validation and yield undefined behaviour downstream.
Add a minimal length (or strip_whitespace=True) to guard against accidental empty submissions:

-    query: str = Field(
-        description="The query string",
-        examples=["What is Kubernetes?"],
-    )
+    query: str = Field(
+        ...,
+        min_length=1,
+        description="The query string (must contain at least one character)",
+        examples=["What is Kubernetes?"],
+    )
📝 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
query: str = Field(
description="The query string",
examples=["What is Kubernetes?"],
)
query: str = Field(
...,
min_length=1,
description="The query string (must contain at least one character)",
examples=["What is Kubernetes?"],
)
🤖 Prompt for AI Agents
In src/models/requests.py around lines 88 to 92, the query field currently
allows empty strings which can cause undefined behavior downstream. To fix this,
enforce that the query is non-empty by adding a minimal length constraint or
setting strip_whitespace=True in the Field definition. Also update the
description to document that the query must not be empty.

Comment on lines +93 to +98
conversation_id: Optional[str] = Field(
None,
description="The optional conversation ID (UUID)",
examples=["c5260aec-4d82-4370-9fdf-05cf908b3f16"],
)

Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Validate conversation_id the same way as in FeedbackRequest

You already have suid.check_suid() available and use it in another model. Re-using that validator here prevents malformed UUIDs from leaking into persistence layers and log correlation.

@@
     conversation_id: Optional[str] = Field(
         None,
         description="The optional conversation ID (UUID)",
         examples=["c5260aec-4d82-4370-9fdf-05cf908b3f16"],
     )
+
+    @field_validator("conversation_id")
+    @classmethod
+    def _validate_conversation_id(cls, v: Optional[str]) -> Optional[str]:
+        if v is None:
+            return v
+        if not suid.check_suid(v):
+            raise ValueError(f"Improper conversation ID {v}")
+        return v
📝 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
conversation_id: Optional[str] = Field(
None,
description="The optional conversation ID (UUID)",
examples=["c5260aec-4d82-4370-9fdf-05cf908b3f16"],
)
conversation_id: Optional[str] = Field(
None,
description="The optional conversation ID (UUID)",
examples=["c5260aec-4d82-4370-9fdf-05cf908b3f16"],
)
@field_validator("conversation_id")
@classmethod
def _validate_conversation_id(cls, v: Optional[str]) -> Optional[str]:
if v is None:
return v
if not suid.check_suid(v):
raise ValueError(f"Improper conversation ID {v}")
return v
🤖 Prompt for AI Agents
In src/models/requests.py around lines 93 to 98, the conversation_id field lacks
validation to ensure it is a properly formed UUID. To fix this, add a validator
for conversation_id that uses suid.check_suid() just like in the FeedbackRequest
model. This will prevent malformed UUIDs from being accepted and improve data
integrity and log correlation.

Comment on lines +111 to +116
system_prompt: Optional[str] = Field(
None,
description="The optional system prompt.",
examples=["You are OpenShift assistant.", "You are Ansible assistant."],
)

Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Add reasonable length cap to system_prompt

system_prompt is free-form text potentially propagated to LLM back-ends. A runaway megabyte-sized prompt could blow up request size or exceed provider limits.
Align with the 4 096-char limit you already apply to user_feedback:

-    system_prompt: Optional[str] = Field(
-        None,
-        description="The optional system prompt.",
-        examples=["You are OpenShift assistant.", "You are Ansible assistant."],
-    )
+    system_prompt: Optional[str] = Field(
+        None,
+        max_length=4096,
+        description="The optional system prompt.",
+        examples=["You are OpenShift assistant.", "You are Ansible assistant."],
+    )
📝 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
system_prompt: Optional[str] = Field(
None,
description="The optional system prompt.",
examples=["You are OpenShift assistant.", "You are Ansible assistant."],
)
system_prompt: Optional[str] = Field(
None,
max_length=4096,
description="The optional system prompt.",
examples=["You are OpenShift assistant.", "You are Ansible assistant."],
)
🤖 Prompt for AI Agents
In src/models/requests.py around lines 111 to 116, the system_prompt field lacks
a length limit, which risks excessively large inputs causing issues with LLM
back-ends. Add a max_length constraint of 4096 characters to the system_prompt
Field definition, similar to the existing limit on user_feedback, to prevent
oversized prompts.

@tisnik tisnik merged commit f843245 into lightspeed-core:main Aug 6, 2025
18 checks passed
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