fix: MCP tools query nonexistent KuzuDB relationship tables#58
fix: MCP tools query nonexistent KuzuDB relationship tables#58zm2231 wants to merge 4 commits intoharshkedia177:mainfrom
Conversation
|
Addressed the remote embedding parity issue and tightened the HTTP backend contract. What was wrongThe remote backend returns plain Python lists, but the incremental embed path still assumed ndarray-like vectors and called What changed
Verified
This should eliminate the repeated watcher failures caused by the remote provider returning plain lists, and makes the HTTP path behave much more like the local Also debugged the restart issue locally: the immediate crash after killing the runaway host was a bad Kuzu WAL, not the base DB file. Removing the WAL let the host start cleanly again. |
The MCP tools in tools.py query COUPLED_WITH, MEMBER_OF, and STEP_IN_PROCESS as standalone KuzuDB relationship tables, but kuzu_backend.py stores all relationships in a single CodeRelation table group with rel_type as a string property. When a repo has few/no edges of a given type, KuzuDB never creates the table, causing 'Table X does not exist' errors in: - axon_file_context - axon_coupling - axon_communities - axon_explain Fix: replace the relationship table names with CodeRelation and filter by rel_type property where needed. For MEMBER_OF and STEP_IN_PROCESS, the target node type (Community/Process) already disambiguates without an explicit rel_type filter.
d9aa6d1 to
75f19c8
Compare
|
Updated this PR branch with the rebased/fixed version. It now includes the original MCP relationship-table fix plus follow-up commits for end-to-end remote embedding support, provider-native dimensions, and environment refresh in long-lived processes. Please review the refreshed PR body for the current behavior and verification details. |
Rebased PR #58 onto latest upstream main and extended it to fully support the configured remote embedding provider end-to-end.
This now:
Verified with:
Operational note: