LCORE-755: Fixed feedback endpoint responds correctly without sentiment and empty user_feedback

[asimurka]

Description

This PR updates the FeedbackRequest model validator to treat empty strings for user_feedback as invalid, ensuring that at least one form of feedback (sentiment, user_feedback, or categories) must be provided.

It adds a unit test for this case and a corresponding e2e test for endpoint validation.

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-755
• Closes #

Checklist before requesting a review

• I have performed a self-review of my code.
• PR has passed all pre-merge test jobs.
• If it is a core feature, I have added thorough tests.

Testing

• Please provide detailed steps to perform tests related to this code change.
• How were the fix/results from this change verified? Please provide relevant screenshots or results.

Summary by CodeRabbit

• Bug Fixes
  • Improved feedback validation to require at least one form of feedback: sentiment, feedback text, or categories. Empty feedback submissions will no longer be accepted.

[coderabbitai]

Walkthrough

The pull request tightens feedback validation by treating empty user_feedback strings as non-provided input. The validator now requires at least one form of feedback (sentiment, non-empty user_feedback, or categories) to be present. Corresponding unit and end-to-end tests verify this stricter validation behavior.

Changes

Cohort / File(s)	Summary
Model Validator src/models/requests.py	Updated check_feedback_provided guard condition to treat empty user_feedback as non-provided feedback, requiring at least one of sentiment, non-empty user_feedback, or categories
Test Coverage tests/unit/models/requests/test_feedback_request.py	Added test_empty_user_feedback_not_sufficient to assert ValueError when user_feedback is empty
Endpoint Tests tests/unit/app/endpoints/test_feedback.py	Extended imports with FeedbackRequest, added MOCK_AUTH and VALID_BASE constants, introduced parameterized test test_feedback_endpoint_valid_requests validating various valid feedback payload shapes
E2E Scenario tests/e2e/features/feedback.feature	Added scenario verifying that empty user_feedback submission returns 422 Unprocessable Entity with appropriate error message

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

The changes follow a consistent pattern of validation tightening paired with corresponding test coverage. The logic modifications are straightforward, and the test additions, while spread across multiple files, are homogeneous in nature and repetitive in structure.

Poem

🐰 Hop, hop, the feedback must be true,
No empty strings will slip on through!
Sentiment, words, or tags galore—
Pick at least one, that's what we're for!
Validation's strict, but oh so fair, 🐇✨

Pre-merge checks and finishing touches

✅ 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 "LCORE-755: Fixed feedback endpoint responds correctly without sentiment and empty user_feedback" is clearly related to the primary change in this changeset. The title specifically references the scenario being addressed: the case where sentiment is absent and user_feedback is empty, which is the exact condition the validator update now handles by rejecting it as invalid feedback. The title is specific and concrete—identifying the particular conditions being validated—rather than vague or generic, and a teammate scanning the commit history would understand that this PR addresses validation behavior for a specific feedback submission scenario.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f4f6684 and af7de68.

📒 Files selected for processing (4)

• src/models/requests.py (1 hunks)
• tests/e2e/features/feedback.feature (1 hunks)
• tests/unit/app/endpoints/test_feedback.py (2 hunks)
• tests/unit/models/requests/test_feedback_request.py (1 hunks)

🧰 Additional context used

📓 Path-based instructions (7)

tests/e2e/features/**/*.feature

📄 CodeRabbit inference engine (CLAUDE.md)

Write E2E tests as Gherkin feature files for behave

Files:

• tests/e2e/features/feedback.feature

**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.py: All modules start with descriptive module-level docstrings explaining purpose
Use logger = logging.getLogger(name) for module logging after import logging
Define type aliases at module level for clarity
All functions require docstrings with brief descriptions
Provide complete type annotations for all function parameters and return types
Use typing_extensions.Self in model validators where appropriate
Use modern union syntax (str | int) and Optional[T] or T | None consistently
Function names use snake_case with descriptive, action-oriented prefixes (get_, validate_, check_)
Avoid in-place parameter modification; return new data structures instead of mutating arguments
Use appropriate logging levels: debug, info, warning, error with clear messages
All classes require descriptive docstrings explaining purpose
Class names use PascalCase with conventional suffixes (Configuration, Error/Exception, Resolver, Interface)
Abstract base classes should use abc.ABC and @AbstractMethod for interfaces
Provide complete type annotations for all class attributes
Follow Google Python docstring style for modules, classes, and functions, including Args, Returns, Raises, Attributes sections as needed

Files:

• tests/unit/models/requests/test_feedback_request.py
• src/models/requests.py
• tests/unit/app/endpoints/test_feedback.py

tests/{unit,integration}/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

tests/{unit,integration}/**/*.py: Use pytest for all unit and integration tests
Do not use unittest in tests; pytest is the standard

Files:

• tests/unit/models/requests/test_feedback_request.py
• tests/unit/app/endpoints/test_feedback.py

tests/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

tests/**/*.py: Use pytest-mock to create AsyncMock objects for async interactions in tests
Use the shared auth mock constant: MOCK_AUTH = ("mock_user_id", "mock_username", False, "mock_token") in tests

Files:

• tests/unit/models/requests/test_feedback_request.py
• tests/unit/app/endpoints/test_feedback.py

src/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

Use absolute imports for internal modules (e.g., from auth import get_auth_dependency)

Files:

• src/models/requests.py

src/{models/**/*.py,configuration.py}

📄 CodeRabbit inference engine (CLAUDE.md)

src/{models/**/*.py,configuration.py}: Use @field_validator and @model_validator for custom validation in Pydantic models
Use precise type hints in configuration (e.g., Optional[FilePath], PositiveInt, SecretStr)

Files:

• src/models/requests.py

src/models/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

src/models/**/*.py: Pydantic models: use BaseModel for data models and extend ConfigurationBase for configuration
Use @model_validator and @field_validator for Pydantic model validation

Files:

• src/models/requests.py

🧬 Code graph analysis (2)

tests/unit/models/requests/test_feedback_request.py (1)

src/models/requests.py (1)

• FeedbackRequest (244-387)

tests/unit/app/endpoints/test_feedback.py (3)

src/models/requests.py (1)

• FeedbackRequest (244-387)

tests/unit/utils/auth_helpers.py (1)

• mock_authorization_resolvers (8-26)

src/app/endpoints/feedback.py (1)

• feedback_endpoint_handler (88-126)

⏰ 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). (1)

• GitHub Check: e2e_tests (ci)

🔇 Additional comments (5)

src/models/requests.py (1)

375-387: LGTM! Empty string validation correctly implemented.

The validator now properly treats empty user_feedback strings as insufficient feedback, requiring at least one of: sentiment, non-empty user_feedback, or categories. The logic is clear and the error message is actionable.

tests/unit/models/requests/test_feedback_request.py (1)

186-198: LGTM! Test properly validates empty string feedback.

The test correctly verifies that an empty user_feedback string (with no other feedback forms) raises the expected validation error. Good isolation with explicit None values for other feedback fields.

tests/unit/app/endpoints/test_feedback.py (2)

19-24: LGTM! Test constants improve reusability.

The MOCK_AUTH and VALID_BASE constants provide clean, reusable test fixtures that reduce duplication and improve test readability. The auth tuple structure aligns with the expected pattern.

---

243-263: LGTM! Comprehensive validation of individual feedback forms.

The parametrized test properly validates that each feedback form (sentiment, user_feedback, or categories) is individually sufficient. Using the actual FeedbackRequest model ensures the validation logic is exercised, providing better coverage than mock-based tests.

tests/e2e/features/feedback.feature (1)

295-320: I'll explore the codebase to verify the expected error response structure by examining the validator implementation and comparing it with other test scenarios.Now let me search for information about model_validator specifically and what it includes in error responses:Now let me search the codebase to find the feedback model and its validator:

Now let me search the codebase directly for the feedback model and validator:

Based on my research into Pydantic v2's validator behavior, I can now provide a definitive response about the review comment:

The expected error response structure likely needs correction.

In Pydantic V2, mode='after' validators are instance methods and always receive an instance of the model as the first argument. When the check_feedback_provided validator (decorated with @model_validator(mode="after")) raises a ValueError, Pydantic v2 captures the entire model instance in the error detail's input field, not just the problematic field.

The test currently expects:

"input": {
    "user_feedback": ""
}

However, given that the validator receives the full model after field validation, the actual error response will likely include all request fields:

"input": {
    "user_question": "Sample Question",
    "llm_response": "Sample Response",
    "user_feedback": ""
}

Update the expected error structure at lines 315-317 to include all request fields:

"input": {
    "user_question": "Sample Question",
    "llm_response": "Sample Response",
    "user_feedback": ""
}

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[tisnik]

LGTM