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

124-135: 🛠️ Refactor suggestion

⚠️ Potential issue

Unused embedding computation & wrong argument – avoid double work

An embedding is generated (query_vector) but never passed to search; instead, query_text is supplied, forcing the adapter to re‑embed the same string. This doubles compute cost and latency.

-            query_vector = await vector_engine.embed_data([query])
-            query_vector = query_vector[0]
-            if query_vector is None or len(query_vector) == 0:
-                raise ValueError("Failed to generate query embedding.")
-
-            edge_distances = await vector_engine.search(
-                collection_name="EdgeType_relationship_name",
-                query_text=query,
-                limit=0,
-            )
+            query_vector = (await vector_engine.embed_data([query]))[0]
+            if not query_vector:
+                raise ValueError("Failed to generate query embedding.")
+
+            edge_distances = await vector_engine.search(
+                collection_name="EdgeType_relationship_name",
+                query_vector=query_vector,   # reuse pre‑computed embedding
+                limit=0,
+            )

Side note: limit=0 is translated to None inside the adapter. Confirm that this yields the intended “unlimited results” behaviour with your backend.

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

148-165: ⚠️ Potential issue

retrieve() returns raw dicts, breaking the interface contract

VectorDBInterface.retrieve() is expected to return List[ScoredResult] (or equivalent), but this implementation returns Milvus‑specific dictionaries. Down‑stream code expecting ScoredResult will break.
Convert the results:

-            return results
+            return [
+                ScoredResult(id=parse_id(row["id"]), payload=row, score=0)
+                for row in results
+            ]

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

160-177: ⚠️ Potential issue

normalize_distances gets raw dataframe rows, missing _distance key

normalize_distances expects an iterable of dicts containing _distance; passing result_values as produced by to_dict() means the function cannot find distances and will raise or return nonsense.
Map the results first:

-result_values = list(results.to_dict("index").values())
+result_values = [
+    {
+        "id": row["id"],
+        "payload": row["payload"],
+        "_distance": row["distance"],
+    }
+    for row in results.to_dict("index").values()
+]

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

80-88: 🛠️ Refactor suggestion

O(N²) vector lookup in create_data_points

data_points.index(data_point) inside a loop gives quadratic complexity. Use enumerate to fetch the already‑computed vector in O(N).

-        def convert_to_weaviate_data_points(data_point: DataPoint):
-            vector = data_vectors[data_points.index(data_point)]
+        def convert_to_weaviate_data_points(idx: int, data_point: DataPoint):
+            vector = data_vectors[idx]
 ...
-data_points = [convert_to_weaviate_data_points(data_point) for data_point in data_points]
+data_points = [
+    convert_to_weaviate_data_points(idx, dp) for idx, dp in enumerate(data_points)
+]

cognee/infrastructure/databases/vector/chromadb/ChromaDBAdapter.py (3)

314-317: 🛠️ Refactor suggestion

get_collection_names should normalise to a list of strings

Returning the raw objects leaks implementation details and complicates every consumer (see previous bug).
Convert once here and keep the public contract simple.

-        return await client.list_collections()
+        # Chroma returns a list of Collection objects / dicts.
+        collections = await client.list_collections()
+        return [
+            c.name if hasattr(c, "name") else c["name"]
+            for c in collections
+        ]

After this change you can simplify has_collection to:

return collection_name in await self.get_collection_names()

---

184-201: ⚠️ Potential issue

Parameter normalized is unused & limit = 0 may DOS the service

1. The normalized flag is accepted but ignored. Either honour it or drop the parameter.

2. Converting limit == 0 into await collection.count() can explode to the full collection size, potentially overwhelming memory / network.
   Prefer a hard cap or require the caller to pass an explicit positive integer.

Example fix:

-        if limit == 0:
-            limit = await collection.count()
+        if limit == 0:
+            raise InvalidValueError(
+                message="Limit must be greater than 0; requesting the whole "
+                "collection is not supported."
+            )

and use normalized when post‑processing:

if normalized:
    normalized_values = normalize_distances(vector_list)
else:
    normalized_values = [1 - item["_distance"] for item in vector_list]  # or raw

---

239-242: 🛠️ Refactor suggestion

Catching bare Exception hides programming errors

Swallowing every exception and returning an empty list makes debugging impossible and may produce silent data loss.
Catch only anticipated runtime errors (CollectionNotFoundError, network time‑outs, etc.) and re‑raise the rest.

-        except Exception as e:
-            logger.error(f"Error in search: {str(e)}")
-            return []
+        except CollectionNotFoundError:
+            raise
+        except RuntimeError as e:  # adjust to concrete chromadb errors
+            logger.error(f"ChromaDB search failed: {e}")
+            return []

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

145-147: limit=0 fetches the entire collection – check scalability

The adapter interprets limit=0 as no limit, potentially returning every vector in large collections.
For most ranking scenarios only the top results are needed:

-                vector_engine.search(collection_name=collection_name, query_text=query, limit=0)
+                vector_engine.search(
+                    collection_name=collection_name,
+                    query_text=query,
+                    limit=top_k   # or another reasonable cap
+                )

Please verify the desired behaviour and adjust to prevent unnecessary load.

cognee/infrastructure/databases/vector/qdrant/QDrantAdapter.py (1)

183-204: Duplicate client.close() call – tidy up resource handling

await client.close() is executed inside the try and the finally block. Double closing is redundant and can raise errors in future client versions.

-            await client.close()
-            return [
+            return [
                 ScoredResult(
                     ...
                 )
             ]

Keep the single close in the finally block to centralise cleanup logic.

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

210-210: with_vector parameter is ignored

The method declares with_vector but never includes the vector in the output when it is True. Either honour it (e.g. add a vector field to ScoredResult) or remove the parameter to avoid a misleading API.

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

153-155: Minor: shadowing the built‑in id inside f‑string comprehension

While harmless, using id as the loop variable shadows Python’s built‑in id() which can confuse readers.

", ".join(f'"{dp_id}"' for dp_id in data_point_ids)

---

193-210: Consider normalising Milvus distances for consistency

Other adapters map raw distances to a 0‑1 score via normalize_distances. Returning bare distances here makes score semantics adapter‑specific and complicates ranking across back‑ends.

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

165-167: limit == 0 semantics rely on an extra DB call

Calling await collection.count_rows() for every unlimited search adds latency. Consider treating limit <= 0 as None and letting LanceDB handle “no limit”, mirroring other adapters.

cognee/infrastructure/databases/vector/chromadb/ChromaDBAdapter.py (2)

121-127: Avoid double round‑trip in get_collection

has_collection() already hits the server. Immediately calling client.get_collection() makes a second request even when the collection is missing.
You can rely on the single get_collection call and catch the provider‑specific exception, mapping it to CollectionNotFoundError, e.g.:

-        if not await self.has_collection(collection_name):
-            raise CollectionNotFoundError(f"Collection '{collection_name}' not found!")
-
-        client = await self.get_connection()
-        return await client.get_collection(collection_name)
+        client = await self.get_connection()
+        try:
+            return await client.get_collection(collection_name)
+        except Exception:
+            # Map the provider error to the domain error
+            raise CollectionNotFoundError(
+                f"Collection '{collection_name}' not found!"
+            ) from None

This halves latency and network traffic for the common case.

---

253-261: Keep default limit consistent with search

search now defaults to limit=15 while batch_search still uses limit=5.
Recommend aligning both to avoid surprising behaviour.

-        limit: int = 5,
+        limit: int = 15,

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