Reviewing files that changed from the base of the PR and between 2faf238 and ad0bb0c.

• .github/actions/cognee_setup/action.yml is excluded by !**/*.yml
• .github/workflows/python_version_tests.yml is excluded by !**/*.yml
• .github/workflows/test_memgraph.yml is excluded by !**/*.yml
• assets/cognee_benefits.png is excluded by !**/*.png, !**/*.png
• assets/graph_visualization.png is excluded by !**/*.png, !**/*.png
• cognee-mcp/pyproject.toml is excluded by !**/*.toml
• cognee-mcp/uv.lock is excluded by !**/*.lock, !**/*.lock
• poetry.lock is excluded by !**/*.lock, !**/*.lock
• pyproject.toml is excluded by !**/*.toml
• uv.lock is excluded by !**/*.lock, !**/*.lock

• CONTRIBUTING.md (1 hunks)
• Dockerfile (1 hunks)
• README.md (2 hunks)
• assets/graph_visualization.html (0 hunks)
• cognee-frontend/src/app/page.tsx (3 hunks)
• cognee-frontend/src/app/wizard/CognifyStep/CognifyStep.tsx (1 hunks)
• cognee-frontend/src/app/wizard/ExploreStep/ExploreStep.tsx (1 hunks)
• cognee-frontend/src/app/wizard/WizardPage.tsx (1 hunks)
• cognee-frontend/src/modules/datasets/cognifyDataset.ts (1 hunks)
• cognee-frontend/src/modules/exploration/getExplorationGraphUrl.ts (1 hunks)
• cognee-frontend/src/modules/ingestion/DataView/DataView.tsx (4 hunks)
• cognee-frontend/src/ui/Partials/Explorer/Explorer.tsx (1 hunks)
• cognee-frontend/src/ui/Partials/SearchView/SearchView.tsx (2 hunks)
• cognee-frontend/src/utils/fetch.ts (1 hunks)
• cognee-mcp/src/server.py (3 hunks)
• cognee/api/v1/add/add.py (1 hunks)
• cognee/api/v1/cognify/code_graph_pipeline.py (3 hunks)
• cognee/api/v1/cognify/cognify.py (1 hunks)
• cognee/api/v1/datasets/datasets.py (1 hunks)
• cognee/base_config.py (1 hunks)
• cognee/exceptions/exceptions.py (1 hunks)
• cognee/infrastructure/databases/graph/get_graph_engine.py (1 hunks)
• cognee/infrastructure/databases/graph/graph_db_interface.py (2 hunks)
• cognee/infrastructure/databases/graph/memgraph/memgraph_adapter.py (1 hunks)
• cognee/infrastructure/databases/graph/networkx/adapter.py (7 hunks)
• cognee/infrastructure/databases/relational/sqlalchemy/SqlAlchemyAdapter.py (2 hunks)
• cognee/infrastructure/databases/vector/chromadb/ChromaDBAdapter.py (8 hunks)
• cognee/infrastructure/databases/vector/exceptions/exceptions.py (1 hunks)
• cognee/infrastructure/databases/vector/lancedb/LanceDBAdapter.py (8 hunks)
• cognee/infrastructure/databases/vector/milvus/MilvusAdapter.py (9 hunks)
• cognee/infrastructure/databases/vector/pgvector/PGVectorAdapter.py (5 hunks)
• cognee/infrastructure/databases/vector/qdrant/QDrantAdapter.py (6 hunks)
• cognee/infrastructure/databases/vector/weaviate_db/WeaviateAdapter.py (9 hunks)
• cognee/infrastructure/llm/gemini/adapter.py (1 hunks)
• cognee/infrastructure/llm/openai/adapter.py (2 hunks)
• cognee/modules/data/methods/__init__.py (1 hunks)
• cognee/modules/data/methods/create_dataset.py (2 hunks)
• cognee/modules/data/methods/get_unique_dataset_id.py (1 hunks)
• cognee/modules/graph/cognee_graph/CogneeGraph.py (1 hunks)
• cognee/modules/observability/get_observe.py (1 hunks)
• cognee/modules/observability/observers.py (1 hunks)
• cognee/modules/pipelines/models/PipelineRun.py (1 hunks)
• cognee/modules/pipelines/operations/__init__.py (1 hunks)
• cognee/modules/pipelines/operations/get_pipeline_status.py (2 hunks)
• cognee/modules/pipelines/operations/log_pipeline_run_initiated.py (1 hunks)
• cognee/modules/pipelines/operations/pipeline.py (3 hunks)
• cognee/modules/pipelines/operations/run_tasks.py (4 hunks)
• cognee/modules/pipelines/operations/run_tasks_base.py (4 hunks)
• cognee/modules/retrieval/exceptions/__init__.py (1 hunks)
• cognee/modules/retrieval/exceptions/exceptions.py (0 hunks)
• cognee/modules/retrieval/graph_completion_retriever.py (1 hunks)
• cognee/modules/retrieval/utils/brute_force_triplet_search.py (4 hunks)
• cognee/modules/settings/get_settings.py (2 hunks)
• cognee/shared/data_models.py (0 hunks)
• cognee/shared/logging_utils.py (1 hunks)
• cognee/tasks/ingestion/ingest_data.py (1 hunks)
• cognee/tasks/temporal_awareness/index_graphiti_objects.py (2 hunks)
• cognee/tests/integration/run_toy_tasks/conftest.py (0 hunks)
• cognee/tests/test_memgraph.py (1 hunks)
• cognee/tests/test_neo4j.py (1 hunks)
• cognee/tests/test_weaviate.py (1 hunks)
• cognee/tests/unit/modules/pipelines/run_tasks_test.py (1 hunks)
• cognee/tests/unit/modules/pipelines/run_tasks_with_context_test.py (1 hunks)
• cognee/tests/unit/modules/retrieval/chunks_retriever_test.py (4 hunks)
• cognee/tests/unit/modules/retrieval/graph_completion_retriever_test.py (1 hunks)
• cognee/tests/unit/modules/retrieval/summaries_retriever_test.py (1 hunks)
• cognee/tests/unit/modules/retrieval/utils/brute_force_triplet_search_test.py (0 hunks)
• entrypoint.sh (3 hunks)
• examples/data/car_and_tech_companies.txt (1 hunks)
• examples/python/graphiti_example.py (2 hunks)
• notebooks/cognee_demo.ipynb (3 hunks)
• notebooks/cognee_graphiti_demo.ipynb (4 hunks)
• notebooks/cognee_llama_index.ipynb (2 hunks)
• notebooks/cognee_simple_demo.ipynb (7 hunks)
• notebooks/github_graph_visualization.html (0 hunks)
• notebooks/graphrag_vs_rag.ipynb (7 hunks)
• notebooks/hr_demo.ipynb (0 hunks)
• notebooks/llama_index_cognee_integration.ipynb (5 hunks)

• cognee/modules/retrieval/exceptions/exceptions.py
• cognee/shared/data_models.py
• cognee/tests/unit/modules/retrieval/utils/brute_force_triplet_search_test.py
• cognee/tests/integration/run_toy_tasks/conftest.py
• notebooks/github_graph_visualization.html
• assets/graph_visualization.html
• notebooks/hr_demo.ipynb

cognee/tests/unit/modules/retrieval/summaries_retriever_test.py (1)

130-130: Good parameter naming alignment with the implementation.

The change from limit=20 to top_k=20 correctly aligns the test with the actual implementation of SummariesRetriever, which accepts top_k as a constructor parameter and then uses it internally as the limit parameter when calling the vector engine. This change is part of the broader standardization of parameter naming conventions across retrieval modules.

cognee/tests/unit/modules/retrieval/graph_completion_retriever_test.py (1)

157-162: Good refactoring of test execution pattern!

Converting individual test calls to a sequential async main function improves test organization and efficiency. This approach:

• Ensures tests run in a predictable order
• Uses a single event loop for all tests rather than creating/destroying multiple loops
• Follows the async/await pattern consistently throughout the test file
• Matches the pattern used in other retrieval test modules

cognee/tests/unit/modules/retrieval/chunks_retriever_test.py (4)

19-19: Good test isolation improvement

Using a test-specific directory path (test_chunks_context_simple) provides better isolation between test cases and prevents data leakage between tests.

Also applies to: 23-23

---

76-77: Good test isolation improvement

Using a test-specific directory path (test_chunk_context_complex) ensures that this test's data doesn't interfere with other tests. This also makes debugging easier when a specific test fails.

Also applies to: 80-81

---

165-166: Good test isolation improvement

Using a dedicated directory path (test_chunk_context_empty) for the empty graph test ensures accurate testing of the empty state behavior without interference from other test data.

Also applies to: 169-170

---

193-198: Good refactoring of test execution pattern!

Converting multiple individual test calls to a single async main function is an improvement that:

• Ensures consistent use of the async/await pattern
• Prevents multiple event loop creation/destruction cycles
• Makes test execution more predictable and maintainable
• Aligns with the pattern used in other retrieval test modules

cognee/infrastructure/databases/relational/sqlalchemy/SqlAlchemyAdapter.py (1)

72-72: Consistency fix in comment formatting.

Fixed apostrophe style in comment from curly to straight, improving code consistency.

cognee/modules/pipelines/models/PipelineRun.py (1)

9-9: Verify database migration for new enum member.

Adding DATASET_PROCESSING_INITIATED to PipelineRunStatus may require an Alembic migration if using a PostgreSQL ENUM type. Please confirm that your migration scripts include this new member, or update the type with an ALTER TYPE statement.

cognee-frontend/src/utils/fetch.ts (1)

4-4: LGTM on URL standardization

Changing from IP address to hostname is a good standardization practice. The functionality remains the same as both "127.0.0.1" and "localhost" resolve to the local machine.

For future improvements, consider using environment variables for the API base URL:

- return global.fetch('http://localhost:8000/api' + url, {
+ return global.fetch((process.env.NEXT_PUBLIC_API_BASE_URL || 'http://localhost:8000/api') + url, {

This would make the application more configurable across different environments.

cognee/tests/test_weaviate.py (1)

85-85: LGTM on adding await keyword

The addition of the await keyword is necessary and correct since the list_all() method has been converted to an asynchronous function as part of the broader WeaviateAdapter refactoring.

This change ensures the test properly waits for the asynchronous operation to complete before asserting that the collections list is empty.

cognee-frontend/src/app/wizard/WizardPage.tsx (1)

32-32: LGTM on standardizing dataset identification

Changing from id to name aligns with the broader standardization of dataset identification throughout the frontend codebase.

This change is consistent with updates in related components like CognifyStep and ExploreStep, which now expect a dataset prop with a name property instead of an id property.

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

37-39: Pipeline naming standardization looks good

The addition of the pipeline_name="cognify_pipeline" parameter helps standardize pipeline identification across the system, allowing for better tracking and filtering of pipeline executions. This aligns well with the changes in the datasets module where the same pipeline name is used for status retrieval.

cognee-frontend/src/ui/Partials/Explorer/Explorer.tsx (1)

10-10: Dataset identification change is aligned with broader architecture updates

Changing the dataset property from { id: string } to { name: string } reflects a shift in how datasets are identified throughout the application. This is consistent with similar changes in other frontend components. The Explorer component correctly handles this change since it only passes the dataset object to other functions without directly accessing specific properties.

examples/python/graphiti_example.py (1)

41-41: Pipeline execution with user context looks good

The updated run_tasks call with the user parameter aligns with the broader updates to the pipeline task execution system.

cognee-frontend/src/app/wizard/ExploreStep/ExploreStep.tsx (2)

5-5: LGTM! Dataset identification unified by name.

The dataset prop type change from { id: string } to { name: string } aligns with the broader frontend refactoring to standardize dataset identification by name rather than ID.

---

11-11: Compatible with corresponding Explorer component changes.

Removed the non-null assertion operator (!) when passing the dataset prop to the Explorer component, which is consistent with the updated type system and how Explorer handles the dataset prop.

README.md (2)

61-61: LGTM! Updated Colab notebook link.

The Google Colab notebook link has been updated to a new URL, ensuring users have access to the latest getting started materials.

---

128-135: Great addition highlighting the new UI capabilities.

The new "cognee UI" section enhances the README by providing users with information about the visual interface, which aligns with the broader frontend improvements in this PR. The screenshot and local setup link make it easy for users to get started with the UI.

cognee/api/v1/add/add.py (1)

2-6: Improved import organization.

The reordering of imports provides better logical grouping of related modules, improving code readability:

1. Pipeline imports grouped together
2. User model below Task
3. Task operations below pipeline definition

No functional changes were made to the code logic, making this a safe improvement.

cognee/infrastructure/llm/openai/adapter.py (2)

5-5: Simplified imports.

Removed unused imports and kept only the essential Type import from the typing module, improving code cleanliness.

---

18-20: Centralized observability implementation.

Replaced conditional import logic with a centralized approach using the new get_observe() function. This change:

1. Improves code consistency across different LLM adapters
2. Centralizes monitoring tool configuration logic
3. Makes the code more maintainable by reducing duplicated conditional logic

This is a good architectural improvement that aligns with the broader observability refactoring in the codebase.

cognee/modules/retrieval/graph_completion_retriever.py (1)

78-78:

✅ Verification successful

Error handling pattern has changed.

The try-except block catching EntityNotFoundError has been removed. Ensure that error handling for entity-not-found scenarios is now properly managed in the get_triplets method or that this error condition is no longer relevant for this code path.

---

🏁 Script executed:

#!/bin/bash
# Search for EntityNotFoundError handling in the get_triplets method or brute_force_triplet_search
rg -A 5 "EntityNotFoundError" cognee/modules/retrieval/utils/brute_force_triplet_search.py

Length of output: 593

---

🏁 Script executed:

#!/bin/bash
echo "1. Locating get_triplets definition in graph_completion_retriever.py"
rg -n "def get_triplets" cognee/modules/retrieval/graph_completion_retriever.py

echo "2. Showing the first 200 lines of graph_completion_retriever.py for context"
sed -n '1,200p' cognee/modules/retrieval/graph_completion_retriever.py

echo "3. Searching for brute_force_triplet_search usage in graph_completion_retriever.py"
rg -n "brute_force_triplet_search" cognee/modules/retrieval/graph_completion_retriever.py

Length of output: 5994

---

Error handling for missing entities is covered upstream
The EntityNotFoundError is caught and suppressed within brute_force_triplet_search, so there’s no need for an additional try-except in get_triplets.

cognee-frontend/src/modules/exploration/getExplorationGraphUrl.ts (1)

3-3:

✅ Verification successful

Breaking change: parameter type changed from id to name.

The function parameter has been changed from { id: string } to { name: string }. This is part of a broader refactor to use dataset names instead of IDs. Ensure all callers of this function have been updated to provide a name property instead of an id.

---

🏁 Script executed:

#!/bin/bash
# Search for instances where getExplorationGraphUrl is called to verify they use name
rg -A 2 "getExplorationGraphUrl" cognee-frontend/src

Length of output: 1050

---

Verified: getExplorationGraphUrl callers updated

• The only invocation found in cognee-frontend/src/ui/Partials/Explorer/Explorer.tsx now passes the full dataset object (which includes name).
• No other call sites of getExplorationGraphUrl remain in the codebase.

No further changes required.

cognee/tasks/ingestion/ingest_data.py (1)

107-107: LGTM!

The change correctly passes the full user object instead of just the user ID to the create_dataset function, which aligns with the updated function signature that now expects a User object as the second parameter.

cognee/infrastructure/databases/graph/graph_db_interface.py (3)

61-61: Logging level changed from error to debug.

The change from logger.error to logger.debug for relationship errors reduces log noise for non-critical issues that are already being handled with rollback. This is a good practice as these exceptions are caught and handled properly within the code flow.

---

81-81: Consistent logging level adjustment for edge relationships.

Similarly to the previous change, the logging level for edge relationship errors has been appropriately reduced from error to debug, maintaining consistency in how these handled exceptions are logged.

---

88-88: Session commit errors now logged at debug level.

The session commit errors are now logged at debug level instead of error level. This change aligns with the overall approach to reduce noise in error logs for handled exceptions.

cognee/modules/graph/cognee_graph/CogneeGraph.py (1)

131-135:

❓ Verification inconclusive

API call updated to use the new unified search interface.

The code has been modernized to use the search method with explicit keyword arguments instead of the deprecated get_distance_from_collection_elements method. This change aligns with broader refactoring across vector database adapters to use a unified search interface.

The parameter limit=0 might need verification - typically a limit of 0 might mean "no results" in some systems while in others it could mean "no limit".

---

🏁 Script executed:

#!/bin/bash
# Check if the search method implementation treats limit=0 appropriately
rg -A 10 "async def search" --type py cognee/infrastructure/databases/vector/

Length of output: 7548

---

I’m inspecting how each adapter handles a limit=0 parameter to confirm that it either returns all results or is treated safely. Running a scan of all search implementations now.

---

Confirm limit=0 Semantics Across All Adapters

The switch from the deprecated get_distance_from_collection_elements to the unified search() interface looks correct. However, passing limit=0 can mean “no results” in some clients rather than “unlimited.” Please verify that each adapter treats limit=0 as intended (e.g. return all matches or a sensible default) and adjust if needed:

• cognee/infrastructure/databases/vector/weaviate_db/WeaviateAdapter.py
• cognee/infrastructure/databases/vector/qdrant/QDrantAdapter.py
• cognee/infrastructure/databases/vector/milvus/MilvusAdapter.py
• cognee/infrastructure/databases/vector/pgvector/PGVectorAdapter.py
• cognee/infrastructure/databases/vector/lancedb/LanceDBAdapter.py
• cognee/infrastructure/databases/vector/chromadb/ChromaDBAdapter.py

cognee/modules/settings/get_settings.py (2)

2-2: Added import for Optional type.

The import for Optional from the typing module has been added to support the type changes in the LLMConfig model.

---

24-25:

✅ Verification successful

LLMConfig fields made optional.

The endpoint and api_version fields in the LLMConfig model have been changed from required strings to optional strings. This provides more flexibility in configuration, especially for LLM providers that might not require these fields.

Make sure that any code using these fields handles the case where they might be None.

---

🏁 Script executed:

#!/bin/bash
# Check usages of endpoint and api_version to ensure they handle None values
rg -A 5 -B 5 "endpoint|api_version" --type py cognee/infrastructure/llm/

Length of output: 15993

---

🏁 Script executed:

#!/bin/bash
# Display the first 200 lines of the settings file to understand context
sed -n '1,200p' cognee/modules/settings/get_settings.py

Length of output: 4448

---

Approved: Optional endpoint/api_version in Settings LLMConfig Are Safe

The endpoint and api_version fields in cognee/modules/settings/get_settings.py are only used to shape the settings payload returned to the UI. Since they’re now Optional[str], Pydantic’s BaseModel will accept None and emit null in the JSON—there’s no dereferencing or logic applied to these values elsewhere in the codebase.

No further changes are required.

cognee-frontend/src/app/wizard/CognifyStep/CognifyStep.tsx (1)

10-10:

✅ Verification successful

Dataset identification changed from id to name.

The dataset prop type has been updated from { id: string } to { name: string }, which aligns with a broader standardization of dataset identification across the application. This change ensures consistent dataset referencing throughout the frontend and backend pipeline.

Verify that the cognifyDataset function properly handles this change in the dataset identification scheme:

---

🏁 Script executed:

#!/bin/bash
# Check the implementation of cognifyDataset to ensure it uses dataset.name
cat src/modules/datasets/cognifyDataset.ts

Length of output: 115

---

🏁 Script executed:

#!/usr/bin/env bash
# Locate the implementation of cognifyDataset to verify it uses dataset.name
rg -n "cognifyDataset" .

Length of output: 584

---

🏁 Script executed:

#!/usr/bin/env bash
# Display the implementation of cognifyDataset to confirm it references dataset.name
sed -n '1,200p' cognee-frontend/src/modules/datasets/cognifyDataset.ts

Length of output: 427

---

Dataset identification change verified in cognifyDataset

The dataset prop has been updated to { name: string } in CognifyStep.tsx, and in src/modules/datasets/cognifyDataset.ts we see:

body: JSON.stringify({
  datasets: [dataset.id || dataset.name],
}),

This ensures that when id is absent, name is used. No further changes are needed.

cognee/modules/observability/observers.py (1)

4-9: LGTM! Good use of string-based enum

The Observer enum inheriting from str and Enum is a good choice, allowing for direct string comparisons without explicit conversions. The enumeration is clear and concise.

cognee/api/v1/datasets/datasets.py (1)

31-31: LGTM! Correct pipeline name specification

The update correctly specifies the pipeline name parameter when calling get_pipeline_status, which aligns with the changes in the pipeline operations module. This maintains the same interface for callers while adapting to the enhanced pipeline management system.

cognee/tests/test_neo4j.py (1)

90-90: LGTM! Correctly updated assertion

The assertion has been properly updated to reflect the removal of the natural language search test. The expected history length is now 6 instead of 8, which is consistent with the commented-out search operation.

cognee/base_config.py (2)

5-5: Consistent enum migration for observability tools.

The import change to use the new Observer enum aligns with the broader refactoring of observability tooling across the codebase.

---

11-11: Type consistency maintained in monitoring tool default.

The change from MonitoringTool.LANGFUSE to Observer.LANGFUSE preserves the same functionality while using the newly defined enum from the observability module.

cognee/modules/pipelines/operations/get_pipeline_status.py (2)

8-8: Function signature updated to support pipeline-specific filtering.

Adding the pipeline_name parameter allows callers to specify which pipeline's status to retrieve, improving the query's specificity.

---

23-23: Enhanced query filtering by pipeline name.

This new filter restricts the status retrieval to runs of the specified pipeline, improving the accuracy of pipeline status reporting.

cognee-frontend/src/app/page.tsx (2)

46-46: Improved user guidance in notification message.

The updated notification clearly informs users of the next step after adding data.

---

106-106: UI enhancement for direct cognification.

Adding the onCognify prop to DataView enables the new UI workflow for triggering dataset cognification directly from the data view.

cognee/infrastructure/llm/gemini/adapter.py (2)

6-7: Well-structured imports for improved observability

The centralized import of the observability module is a good approach, aligning with the broader refactoring of observability tooling across the codebase.

---

17-17: Good centralization of observability configuration

Replacing conditional imports with a centralized function call improves maintainability and consistency. This approach makes it easier to switch monitoring tools if needed in the future.

entrypoint.sh (4)

16-16: Direct Alembic usage aligned with dependency management changes

This change aligns with the shift from Poetry to uv for dependency management, simplifying the migration command.

---

25-25: Helpful migration completion message

Adding this message improves visibility into the startup process.

---

27-27: Simplified startup message

The more generic "Starting server..." message is appropriate since it's no longer specifically referring to Gunicorn.

---

36-37:

❓ Verification inconclusive

Removal of exec might affect signal handling in containers

Removing exec from the server startup commands changes process hierarchy and signal propagation. In containerized environments, this might affect how signals (like SIGTERM) are handled.

Also applies to: 38-39, 41-42

---

🏁 Script executed:

#!/bin/bash
# This script checks if the application is running in a container environment
# and warns about potential signal handling implications

if [ -f /.dockerenv ] || grep -q docker /proc/self/cgroup 2>/dev/null || grep -q kubernetes /proc/self/cgroup 2>/dev/null; then
  echo "WARNING: Application appears to be running in a container environment"
  echo "Without 'exec' prefix, signals may not propagate correctly to the application process."
  echo "This could affect graceful shutdown during container orchestration."
fi

# Check if container orchestration tools are being used
if [ -n "$KUBERNETES_SERVICE_HOST" ] || [ -n "$DOCKER_HOST" ]; then
  echo "Container orchestration detected. Signal handling is particularly important."
fi

Length of output: 130

---

Add exec to server startup for correct signal handling in containers

To ensure the startup process becomes PID 1 and properly receives SIGTERM/SIGINT in Docker/Kubernetes (allowing graceful shutdown), prepend exec to your debugpy/gunicorn commands:

• entrypoint.sh, Lines 36–37, 38–39, 41–42
• Example diff for the debugpy+gunicorn invocation:

-    debugpy --wait-for-client --listen 0.0.0.0:5678 \
-      -m gunicorn -w 3 -k uvicorn.workers.UvicornWorker \
-      -t 30000 --bind=0.0.0.0:8000 --log-level debug \
-      --reload cognee.api.client:app
+    exec debugpy --wait-for-client --listen 0.0.0.0:5678 \
+      -m gunicorn -w 3 -k uvicorn.workers.UvicornWorker \
+      -t 30000 --bind=0.0.0.0:8000 --log-level debug \
+      --reload cognee.api.client:app

Please verify that graceful shutdown behavior in your container orchestration works as expected.

cognee/modules/pipelines/operations/log_pipeline_run_initiated.py (1)

16-21: LGTM: Database session handling follows best practices

The database session handling with async context manager follows best practices for asynchronous database operations.

cognee/infrastructure/databases/graph/get_graph_engine.py (1)

70-80: Good implementation of Memgraph support

The addition of Memgraph support follows the established pattern of the factory function, maintaining consistency with other database providers.

notebooks/cognee_demo.ipynb (3)

470-470: Import path updated to match updated module structure.

The import path for the Task class has been updated to reflect the lowercase module naming convention (task instead of Task), aligning with Python's standard naming practices.

---

508-508: Parameter added to support user context in pipeline execution.

The run_tasks function call has been updated to include the user parameter, which aligns with the broader architectural changes for context propagation in task execution. This change correctly implements the updated function signature.

---

532-536: Explicit user context retrieval implemented.

The code now explicitly retrieves the user context in two steps:

1. Getting the default user
2. Fetching the complete user object with the default user's ID

This approach aligns with the codebase's architectural changes to standardize user context handling across the application.

cognee-frontend/src/ui/Partials/SearchView/SearchView.tsx (2)

81-82: Improved user experience with immediate input clearing

Moving the input clearing to happen immediately after submitting the search rather than waiting for the response provides better feedback to users that their query has been submitted.

---

108-110: Good error handling to preserve user input

Adding error handling to restore the input value if the fetch request fails is an excellent improvement to prevent users from losing their search query when errors occur.

cognee/api/v1/cognify/code_graph_pipeline.py (4)

5-7: Improved observability module organization

Reorganizing the imports for observability-related modules enhances code organization. The get_observe import from a dedicated module suggests a more centralized approach to observability management.

---

16-16: Added dataset ID generation capability

Adding the import for get_unique_dataset_id aligns with the asynchronous dataset ID generation approach and enables user-specific dataset IDs.

---

25-25: Centralized observability configuration

Replacing conditional imports with a centralized call to get_observe() improves code maintainability and provides a cleaner abstraction for observability tooling.

---

68-68: Enhanced dataset ID generation with user context

Switching to an asynchronous call to get_unique_dataset_id with user context is a good improvement that allows for user-specific dataset IDs and better integration with the user management system.

cognee/infrastructure/databases/vector/exceptions/exceptions.py (1)

9-14: Improved exception handling and logging configuration

The changes to the CollectionNotFoundError class enhance error handling by:

1. Making the default exception name consistent with the class name
2. Adding flexible logging control parameters
3. Updating the superclass constructor appropriately

This approach aligns with best practices for exception handling and allows for more granular control over error reporting.

notebooks/cognee_graphiti_demo.ipynb (4)

18-18: Fixed typo in markdown

Simple readability improvement in the notebook documentation.

---

27-29: Updated imports for required modules

Adding the asyncio import and updating the other imports to include get_llm_client and get_default_user properly prepares the notebook for the subsequent code changes.

Also applies to: 42-43

---

131-137: Integrated user context initialization

Simplifying the pruning call and adding the default user initialization is a good improvement that aligns with the broader changes to incorporate user context throughout the system.

---

143-148: Updated task execution with user context

Passing the user object to run_tasks properly integrates the user context into the pipeline execution, ensuring consistent handling of user-related data throughout the system.

cognee/tests/unit/modules/pipelines/run_tasks_with_context_test.py (2)

1-47: Well-structured test for the new context propagation feature.

This test effectively validates that contextual information can be passed through pipeline tasks. The calculation (starting with 5, adding 7, multiplying by 2, then raising to power 7) correctly results in the expected value of 4,586,471,424.

---

14-21: Clear task definitions with proper context usage.

Good implementation of the test tasks with varied parameter patterns:

• task_1 uses both input and context
• task_2 only uses input
• task_3 uses input and context again

This variety helps validate that the context is properly maintained throughout the pipeline execution regardless of whether individual tasks use it.

cognee/modules/data/methods/create_dataset.py (3)

7-8: Appropriate imports for the new implementation.

These imports correctly support the updated function signature that now accepts a User object instead of just an ID.

---

11-12: Good refactoring to accept full User objects.

This change aligns with the broader architectural improvements to propagate context throughout the application. Extracting the owner_id from the user object maintains compatibility with the existing database queries.

---

24-26: Improved dataset ID generation with proper modularization.

Moving the ID generation logic to a separate async helper function improves code organization while maintaining the same uniqueness guarantees (based on dataset name and user ID).

cognee/exceptions/exceptions.py (2)

15-16: Good addition of logging flexibility parameters.

These new parameters allow callers to control whether and at what level exceptions are logged, enhancing observability control.

---

23-30: Improved conditional logging based on log level.

The implementation properly handles different log levels, providing greater flexibility in how exceptions are reported.

cognee-frontend/src/modules/ingestion/DataView/DataView.tsx (3)

9-10: Appropriate UI component imports.

The added imports support the new Cognify functionality with proper UI components.

---

33-33: Well-defined prop interface for the new cognify functionality.

The Promise return type allows for proper async handling of the cognify operation.

---

80-84: Good UI integration of the Cognify button.

The button is well-positioned next to related actions and has appropriate disabled state handling.

notebooks/graphrag_vs_rag.ipynb (5)

56-57: Updated cognee package version.

Updated to use the newer cognee package version (0.1.39), ensuring compatibility with the latest features and API changes.

---

152-153: Updated import path and API usage pattern.

Changed the import for SearchType from cognee.modules.search.types to cognee.api.v1.search and updated the function call to use keyword arguments. This reflects a move to a more stable and explicit API.

---

173-173: Fixed search type constant usage.

Correctly using SearchType.RAG_COMPLETION instead of the previous SearchType.COMPLETION, which is more explicit and accurately describes the search functionality being used.

---

202-202: Updated search function call to use keyword arguments.

Standardized the search function call to use keyword arguments, improving code clarity and alignment with the updated API.

---

246-248: Updated kernel metadata for consistency.

Ensured the notebook's kernel metadata is consistent and compatible with current Python environments, which is good practice for notebook portability.

cognee/modules/pipelines/operations/run_tasks_base.py (1)

17-17: Good implementation of context propagation.

The addition of the optional context parameter with inspection-based conditional passing provides a flexible way to propagate context through the task execution pipeline. This approach maintains backward compatibility while enabling more sophisticated inter-task communication.

Also applies to: 31-36, 66-66, 80-81

Dockerfile (1)

1-61: Excellent improvement with multi-stage build and modern dependency management.

The refactored Dockerfile adopts several best practices:

1. Multi-stage build to minimize the final image size
2. Using uv for faster dependency management instead of Poetry
3. Proper layer caching with separated dependency installation
4. Single RUN command for system dependencies with apt cache cleanup
5. Mount caching for uv operations to speed up builds

These changes should result in faster builds, smaller images, and better maintainability.

cognee/tests/test_memgraph.py (1)

14-108: Well-structured integration test for Memgraph.

This test provides comprehensive coverage of the Memgraph adapter functionality including configuration, data loading, cognification, search operations across multiple query types, and proper cleanup. The test isolation with custom paths is a good practice.

cognee/infrastructure/databases/vector/milvus/MilvusAdapter.py (3)

122-125: Good error handling improvement.

Adding specific exception handling for CollectionNotExistException and raising a custom CollectionNotFoundError provides clearer error information and aligns with error handling standardization across adapters. This makes debugging and error recovery more straightforward.

Also applies to: 161-164, 211-214

---

148-148: Type annotation refinement from str to UUID.

Changing data_point_ids type from list[str] to list[UUID] improves type safety and makes the interface more precise. This helps catch potential type errors earlier in the development process.

Also applies to: 236-236

---

176-176: Search behavior improvements.

The increased default limit (5 → 15) provides more comprehensive search results, and handling non-positive limits by passing None is a robust approach that prevents unexpected behavior.

Also applies to: 196-196

cognee/modules/pipelines/operations/pipeline.py (1)

142-155: get_pipeline_status return-type assumption can break the status checks

task_status is assumed to be a mapping (dict-like) whose keys are str(dataset_id), yet the function call on line 142 provides a list of dataset IDs and—depending on its implementation—could plausibly return:

• a list[PipelineRunStatus],
• a dict[str, PipelineRunStatus], or
• something else entirely.

If it returns a non-mapping type, the subsequent containment check (if str(dataset_id) in task_status:) will raise TypeError or always evaluate to False, allowing duplicate pipeline executions.

Please double-check get_pipeline_status’s signature and update the logic accordingly, or cast the result to the expected structure.

cognee/infrastructure/databases/vector/pgvector/PGVectorAdapter.py (1)

186-188: Great! Raising CollectionNotFoundError improves diagnostics

Explicitly surfacing a typed exception with a controllable log level is a solid improvement over returning None or raising generic errors.
No further action required.

cognee/infrastructure/databases/graph/networkx/adapter.py (1)

139-142: Edge retrieval logic looks good

The switch to UUID propagates correctly into the in_edges/out_edges queries; behaviour is intact.

cognee/infrastructure/databases/vector/weaviate_db/WeaviateAdapter.py (2)

75-81: collections.get may require await – double-check SDK

The async SDK exposes both sync & async variants.
If client.collections.get() returns a coroutine, omitting await will hand back an un-awaited coroutine to downstream code.

Please confirm with the SDK docs; apply await if necessary.

---

167-174: Limit parameter handled nicely

Raising the default search limit to 15 and forwarding None when limit<=0 is clean and keeps API flexible.

cognee/infrastructure/databases/vector/lancedb/LanceDBAdapter.py (1)

76-82: await connection.open_table() – confirm it really is a coroutine

AsyncConnection.open_table is async in current LanceDB (≥0.4), so awaiting is correct.
If your pinned version is older, this will raise TypeError: object is not awaitable.
Double-check the project’s LanceDB version; downgrade compatibility might need:

table = connection.open_table(collection_name)
if inspect.iscoroutine(table):
    table = await table

cognee/modules/retrieval/utils/brute_force_triplet_search.py (4)

4-6: Updated imports for improved error handling.

Added imports for EntityNotFoundError and CollectionNotFoundError exceptions, which are now used for more graceful error handling in the functions below. This aligns with the broader error handling improvements across the codebase.

---

146-153: Extracted search function with improved error handling.

Created a new helper function search_in_collection that encapsulates the vector search call and properly handles the case where a collection doesn't exist. This is a good refactoring that isolates error handling and makes the code more resilient.

---

156-157: Improved handling of empty search results.

The code now uses the new helper function for searches and returns an empty list when no results are found instead of potentially raising an exception. This provides more predictable behavior and a better API experience for callers.

Also applies to: 159-161

---

173-174: Added top-level error handling for collection not found.

The function now catches CollectionNotFoundError at the top level and returns an empty list, further improving resilience. This ensures the function doesn't fail even if there are unexpected collection issues.

cognee/modules/pipelines/operations/run_tasks.py (4)

23-25: Context parameter added to enable task context propagation

The addition of the optional context parameter enhances the pipeline's capability by allowing contextual data to be passed through to tasks that need it.

---

41-41: Context propagation properly passed to run_tasks_base

The context is correctly forwarded to the underlying function, ensuring seamless propagation throughout the execution chain.

---

77-77: Context parameter added to run_tasks function

Adding the optional context parameter here completes the context propagation path through the pipeline execution functions.

---

87-93: Updated function call with named parameters

The function call is updated with named parameters, making the code more readable and explicitly showing the context parameter being passed. This is good practice when functions have multiple parameters.

cognee/tasks/temporal_awareness/index_graphiti_objects.py (6)

23-23: Empty params parameter added for consistency

Adding explicit params={} ensures consistent parameter passing across all graph queries, which is important for standardization and compatibility with different graph database providers.

---

27-29: Query parameters standardized

The relationship name assignment and explicit empty params parameter follow the standardization pattern, ensuring uniform query interfaces across the codebase.

---

30-32: New query added with consistent parameter style

This new query ensures nodes have a text field by coalescing summary and content fields, maintaining the standardized query pattern with explicit params.

---

34-34: Updated method for retrieving graph data

Changing from get_model_independent_graph_data() to get_graph_data() aligns with the new unified graph engine interface that supports multiple graph database providers including the new Memgraph support.

---

36-40: Simplified node data iteration

The iteration pattern has been improved to directly use key-value pairs from the graph data structure, making the code more readable and less prone to indexing errors.

---

64-65: Simplified edge relationship extraction

The code now directly accesses the relationship name at index 2 of each edge tuple, simplifying the previous more complex filtering and indexing logic. This makes the code more maintainable.

notebooks/cognee_llama_index.ipynb (2)

15-17: Notebook cell format standardization looks good.

The source field for this code cell has been updated to use a list format instead of a single string, which aligns with standard Jupyter notebook JSON conventions. This is a purely structural change that doesn't affect code execution or functionality.

---

123-125: Structural field reordering approved.

The metadata and outputs fields in this cell have been reordered, which is again just a format standardization that aligns with Jupyter notebook conventions. This change doesn't affect the code execution or functionality of the notebook.

notebooks/cognee_simple_demo.ipynb (9)

17-19: Package version upgrade to cognee 0.1.39.

The cognee package has been updated from version 0.1.36 to 0.1.39. This appears to be part of the broader architectural changes mentioned in the PR summary.

---

13-16: Notebook metadata standardization looks good.

The execution_count and outputs fields have been properly standardized for this cell. This change improves notebook compatibility without affecting functionality.

---

33-41: Cell metadata formatting standardized.

The execution_count and outputs fields have been standardized for consistency with other notebook cells.

---

53-60: Cell metadata formatting standardized.

The execution_count and outputs fields have been standardized for consistent notebook formatting.

---

72-80: Cell metadata formatting standardized.

The execution_count and outputs fields have been standardized. These changes are structural only and don't affect the code's functionality.

---

92-98: Cell metadata formatting standardized.

The execution_count and outputs fields have been standardized in this cell.

---

102-108: Cell metadata formatting standardized.

The execution_count and outputs fields have been standardized in this cell.

---

112-118: Cell metadata formatting standardized.

The execution_count and outputs fields have been standardized in this cell.

---

130-143: Cell metadata formatting standardized.

The execution_count and outputs fields have been standardized in this visualization cell.

notebooks/llama_index_cognee_integration.ipynb (5)

6-8: Markdown cell formatting standardized.

The source field for this markdown cell has been converted from a single string to a list containing that string, which is a standard Jupyter notebook format. This change doesn't affect functionality.

---

62-64: Code cell formatting standardized.

The source field for this pip install cell has been converted to a list format, which aligns with Jupyter notebook standards. This is a formatting change only.

---

199-201: Markdown cell formatting standardized.

The source field for this markdown cell has been converted to list format, following standard Jupyter notebook conventions.

---

220-221: Markdown cell formatting standardized.

The source field for this conclusion markdown cell has been converted to list format, aligning with Jupyter notebook conventions.

---

282-283: Python version updated in kernel metadata.

The Python version in the language_info metadata has been updated to 3.12.9. This ensures the notebook is associated with the correct Python version.