Add QueryRequest.media_type for backwards compatibility.

[manstis]

Description

Add QueryRequest.media_type for backwards compatibility with road-core clients.

Ansible Lightspeed currently uses road-core and we are switching it to lightspeed-stack.

To avoid making changes to our client code I testing/fixing compatibility issues.

This PR adds media_type but logs that it's use is not supported.

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

• New Features

  • Added support for an optional media type field in requests to improve compatibility with some clients. A warning will be logged if this field is set, as it is currently not supported.

• Tests

  • Introduced new tests to verify logging behavior when the media type field is used in requests.

[coderabbitai]

Walkthrough

An optional media_type field was added to the QueryRequest model, along with a validator that logs a warning if this field is set, noting that it will be ignored. Corresponding unit tests were introduced to ensure this logging behavior is correctly triggered when media_type is provided.

Changes

File(s)	Change Summary
src/models/requests.py	Added optional media_type field and a validator method that logs a warning if it is set.
tests/unit/models/test_requests.py	Added a test to verify warning log emission when media_type is set in QueryRequest.

Poem

A field called media_type hopped in today,
Though unused, it still wants to play.
If you set it, a warning will chime—
“I’ll ignore this, every time!”
With tests in place, the logs are bright,
The code hops forward, feeling light.
🐇

---

📜 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 e5de290 and f7b84db.

📒 Files selected for processing (2)

• src/models/requests.py (3 hunks)
• tests/unit/models/test_requests.py (2 hunks)

🧰 Additional context used

🧬 Code Graph Analysis (1)

src/models/requests.py (1)

src/log.py (1)

• get_logger (7-13)

🔇 Additional comments (5)

src/models/requests.py (3)

8-8: Logger import and initialization looks correct.

The import follows the existing pattern and the logger initialization uses the provided get_logger utility function correctly.

Also applies to: 11-11

---

84-86: Well-documented backwards compatibility field.

The comments clearly explain the purpose of the media_type field and why it's being added. The typing as Optional[str] is appropriate for a backwards compatibility field.

---

139-146: Validator implementation is correct and follows best practices.

The validate_media_type method properly:

• Uses the @model_validator(mode="after") decorator
• Logs a clear warning message when media_type is set
• Returns self to maintain the validation chain
• Only logs when the field is actually set (not None)

The warning message clearly communicates that the field is unsupported and will be ignored.

tests/unit/models/test_requests.py (2)

3-4: Appropriate test imports added.

The Mock and Logger imports are correctly added to support the new test that needs to mock the logger functionality.

---

149-169: Comprehensive test for media_type validation.

The test properly:

• Uses the mocker fixture to mock the logger
• Creates a QueryRequest instance with media_type set
• Verifies that the object is created correctly with all expected attributes
• Asserts that the warning is logged exactly once with the correct message
• Uses the correct mock path (models.requests.logger)

This test ensures the backwards compatibility feature works as intended and provides proper warning to users.

✨ Finishing Touches

• 📝 Generate Docstrings

---

🪧 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.
  • @coderabbitai modularize this function.
• 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.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

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

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

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 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.

[tisnik]

ok!

[umago]

Hmm that means that now we need to implement plain/text for /streaming_query. And IIRC, plain/text was the default format too.

[manstis]

@umago

Hmm that means that now we need to implement plain/text for /streaming_query. And IIRC, plain/text was the default format too.

Yes, I believe the default in road-core was text/plain however in lightspeed-stack there is only support for application/json.