fix: make ontology key an optional param in cognify

[dexters1]

Description

Make ontology key optional in Swagger and None by default (it was "string" by default before change which was causing issues when running cognify endpoint)

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Code refactoring
• Performance improvement
• Other (please specify):

Screenshots/Videos (if applicable)

Pre-submission Checklist

• I have tested my changes thoroughly before submitting this PR
• This PR contains minimal changes necessary to address the issue/feature
• My code follows the project's coding standards and style guidelines
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if applicable)
• All new and existing tests pass
• I have searched existing PRs to ensure this change hasn't been submitted already
• I have linked any relevant issues in the description
• My commits have clear and descriptive messages

DCO Affirmation

I affirm that all code in every commit of this pull request conforms to the terms of the Topoteretes Developer Certificate of Origin.

Summary by CodeRabbit

• Documentation
  • Enhanced API documentation with additional examples and validation metadata to improve request clarity and validation guidance.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[pull-checklist]

Please make sure all the checkboxes are checked:

• I have tested these changes locally.
• I have reviewed the code changes.
• I have added end-to-end and unit tests (if applicable).
• I have updated the documentation and README.md file (if necessary).
• I have removed unnecessary code and debug statements.
• PR title is clear and follows the convention.
• I have tagged reviewers or team members for feedback.

[coderabbitai]

Walkthrough

Added examples=[[]] metadata attribute to the ontology_key field in the CognifyPayloadDTO class. This enriches the API documentation and validation schema while preserving existing field semantics, with no changes to runtime behavior or control flow.

Changes

Cohort / File(s)	Change Summary
API payload metadata enrichment cognee/api/v1/cognify/routers/get_cognify_router.py	Updated ontology_key field in CognifyPayloadDTO to include examples=[[]] alongside existing default=None and description attributes

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Single field metadata modification with no logic or behavioral changes
• Documentation/validation schema enrichment only

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: making the ontology key parameter optional in the cognify endpoint.
Description check	✅ Passed	The description explains the purpose of the change (making ontology key optional and None by default), but the pre-submission checklist items are unchecked, which could indicate incomplete verification.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch make-ontology-key-optional-swagger

---

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

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

cognee/api/v1/cognify/routers/get_cognify_router.py (1)

44-48: Consider more representative examples for API documentation.

The examples=[[]] provides an empty list as an example value, which doesn't demonstrate actual usage of the ontology_key parameter. API consumers would benefit from seeing realistic examples like examples=[["medical_ontology_v1"]] or examples=[["ontology1", "ontology2"]] that show how to reference actual ontology files.

Note: The same pattern appears for dataset_ids on line 39, so this may be an intentional convention. However, the inline docstring example at line 92 demonstrates proper usage with "ontology_key": ["medical_ontology_v1"].

Apply this diff if you'd like to provide more helpful examples:

     ontology_key: Optional[List[str]] = Field(
         default=None,
-        examples=[[]],
+        examples=[["medical_ontology_v1"], ["ontology1", "ontology2"]],
         description="Reference to one or more previously uploaded ontologies",
     )

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 127d986 and 98c6931.

📒 Files selected for processing (1)

• cognee/api/v1/cognify/routers/get_cognify_router.py (1 hunks)

🧰 Additional context used

📓 Path-based instructions (3)

**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

**/*.py: Use 4-space indentation in Python code
Use snake_case for Python module and function names
Use PascalCase for Python class names
Use ruff format before committing Python code
Use ruff check for import hygiene and style enforcement with line-length 100 configured in pyproject.toml
Prefer explicit, structured error handling in Python code

Files:

• cognee/api/v1/cognify/routers/get_cognify_router.py

---

⚙️ CodeRabbit configuration file

**/*.py: When reviewing Python code for this project:

1. Prioritize portability over clarity, especially when dealing with cross-Python compatibility. However, with the priority in mind, do still consider improvements to clarity when relevant.
2. As a general guideline, consider the code style advocated in the PEP 8 standard (excluding the use of spaces for indentation) and evaluate suggested changes for code style compliance.
3. As a style convention, consider the code style advocated in CEP-8 and evaluate suggested changes for code style compliance.
4. As a general guideline, try to provide any relevant, official, and supporting documentation links to any tool's suggestions in review comments. This guideline is important for posterity.
5. As a general rule, undocumented function definitions and class definitions in the project's Python code are assumed incomplete. Please consider suggesting a short summary of the code for any of these incomplete definitions as docstrings when reviewing.

Files:

• cognee/api/v1/cognify/routers/get_cognify_router.py

cognee/api/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

Public APIs should be type-annotated in Python where practical

Files:

• cognee/api/v1/cognify/routers/get_cognify_router.py

cognee/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

Use shared logging utilities from cognee.shared.logging_utils in Python code

Files:

• cognee/api/v1/cognify/routers/get_cognify_router.py

🧠 Learnings (1)

📓 Common learnings

Learnt from: Vattikuti-Manideep-Sitaram
Repo: topoteretes/cognee PR: 1529
File: cognee/api/v1/cognify/ontology_graph_pipeline.py:0-0
Timestamp: 2025-10-13T13:18:46.315Z
Learning: In cognee/api/v1/cognify/ontology_graph_pipeline.py, the `format` parameter in `load_ontology_data` function must be required (not optional) to ensure reliable RDF parsing, as rdflib's auto-detection is unreliable.

⏰ 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: CLI Tests / CLI Functionality Tests
• GitHub Check: CLI Tests / CLI Integration Tests