_find_tables schedules one graph query per embedding without a concurrency bound

[Nievesjyl]

Description

_find_tables() processes the supplied embeddings by starting one graph query for each embedding concurrently.

There is no concurrency bound around these per-embedding graph queries.

As a result, the number of simultaneously active graph queries grows directly with the number of embeddings supplied to the function.

I reproduced this behavior with 512 controlled embeddings.

Observed behavior:

Input embeddings: 512
Peak active graph queries: 512
Pending child tasks before release: 512
External service contacted: No

A large embedding collection can therefore produce a correspondingly large burst of outstanding graph queries instead of maintaining bounded query concurrency.

Affected Version

Confirmed on:

queryweaver==0.3.1
Python 3.12.13
api/graph.py:105-138
_find_tables()

Other versions have not been tested.

Reproduction

The attached PoC executes the released _find_tables() implementation with 512 controlled embeddings.

The graph-query boundary is replaced with a local asynchronous operation that records active calls and waits on a shared gate. This allows the number of graph queries admitted by _find_tables() to be measured before any operation completes.

Observed result:

input embeddings: 512
peak active queries: 512
pending child tasks before release: 512
fan-out reproduced: yes

All 512 graph queries become active before any of them is released.

No graph database or other external service is contacted during reproduction.

Expected behavior

Graph-query concurrency should remain bounded for large embedding collections rather than growing directly with the total number of input embeddings.

A semaphore, bounded worker pool, or batched scheduling strategy could preserve concurrent querying while limiting the number of simultaneously outstanding graph operations.

Attachment

run.py

embeddings.json

[overcut-ai]

Completed Working on "Automated Ticket Triage "

✅ Ticket triage complete for issue #716. Applied labels: bug. No duplicate issue met the similarity threshold, so duplicate was not applied. needs-info was not applied because the report includes sufficient reproduction details, affected version, observed vs expected behavior, and code location.

✅ Workflow completed successfully.

---

👉 View complete log

[overcut-ai]

Completed Working on "Auto Root Cause Analysis"

✅ Workflow completed successfully.

---

👉 View complete log

[overcut-ai]

Root Cause Analysis

_find_tables() in api/graph.py schedules one async graph query per embedding and awaits all tasks together with asyncio.gather(...), without any concurrency limiter. This causes peak concurrent graph queries to scale directly with len(embeddings).

Evidence

• Issue reproduction (this ticket) reports 512 embeddings yielding 512 active graph queries and 512 pending tasks before release.
• Code evidence in api/graph.py:
  • _find_tables: builds per-embedding tasks then await asyncio.gather(*tasks) (unbounded fan-out).
  • _query_graph: thin wrapper around await graph.query(...); no throttling.
• Related same-pattern functions in api/graph.py:
  • _find_tables_by_columns: same unbounded per-embedding gather.
  • _find_tables_sphere: same unbounded gather pattern (over table names).
• Commit-history note: local history available during analysis was limited (top entry 6fdf113 merge), so exact origin commit for this logic could not be fully attributed from local log depth.

Impact Scope

• Directly impacts embedding-driven table retrieval path (_find_tables).
• Likely side effects at larger embedding batches: burst DB load, latency spikes, and higher timeout/resource-pressure risk.
• Adjacent risk exists in helpers that use the same unbounded gather pattern.

Minimal Safe Fix Suggestion

Introduce bounded concurrency for per-embedding graph queries using asyncio.Semaphore, and route _find_tables + _find_tables_by_columns through that helper.

diff --git a/api/graph.py b/api/graph.py
@@
 async def _query_graph(
@@
     result = await graph.query(query, params or {}, timeout=timeout)
     return result.result_set
 
+async def _run_embedding_queries_bounded(
+    graph,
+    query: str,
+    embeddings: List[List[float]],
+    max_concurrency: int = 16,
+) -> List[Dict[str, Any]]:
+    """Run per-embedding graph queries with bounded concurrency."""
+    if not embeddings:
+        return []
+
+    semaphore = asyncio.Semaphore(max_concurrency)
+
+    async def _one(embedding: List[float]):
+        async with semaphore:
+            return await _query_graph(graph, query, {"embedding": embedding})
+
+    results = await asyncio.gather(*[_one(embedding) for embedding in embeddings])
+    return [row for rows in results for row in rows]
+
 async def _find_tables(
@@
-    tasks = [
-        _query_graph(graph, query, {"embedding": embedding})
-        for embedding in embeddings
-    ]
-
-    results = await asyncio.gather(*tasks)
-    return [row for rows in results for row in rows]
+    return await _run_embedding_queries_bounded(graph, query, embeddings)
@@
 async def _find_tables_by_columns(
@@
-    tasks = [
-        _query_graph(graph, query, {"embedding": embedding})
-        for embedding in embeddings
-    ]
-
-    results = await asyncio.gather(*tasks)
-    return [row for rows in results for row in rows]
+    return await _run_embedding_queries_bounded(graph, query, embeddings)

Risk Assessment

• Risk level: Low (localized scheduling change; query semantics and output shape unchanged).
• Expected tradeoff: reduced burst concurrency may increase completion time for very large batches, but this is intentional to protect system stability.

Test Recommendations

1. Async unit test with a gated/monkeypatched _query_graph to verify peak active calls do not exceed configured max_concurrency.
2. Regression tests for _find_tables and _find_tables_by_columns to ensure all rows are still returned and flattened correctly.
3. Optional integration test with larger embedding sets to validate stable behavior under load.

Confidence

High (0.94) — root cause is directly visible in code and aligns exactly with the reported reproduction behavior.