tool_definitions.py:25 declares graph_name as an input to add_code_to_graph:
"graph_name": _GRAPH_NAME_PROP
but the handler never reads it — tools/handlers/indexing_handlers.py:12-21:
def add_code_to_graph(graph_builder, job_manager, loop, list_repos_func, **args) -> Dict[str, Any]:
path = args.get("path") or args.get("repo_path")
is_dependency = args.get("is_dependency", False)
...
Only path, repo_path and is_dependency are consulted. graph_name is silently discarded.
Impact
FalkorDB is the default backend and is multi-graph — list_graphs is an exposed tool (tool_definitions.py:386) and query handlers honour graph_name (handlers/query_handlers.py:46). So an agent can legitimately do:
add_code_to_graph(path="/repos/service-a", graph_name="service-a")
and reasonably believe the repository landed in service-a. It lands in the default graph instead, with no warning. A later analyze_code_relationships(..., graph_name="service-a") then finds nothing, and the failure looks like "indexing didn't work" rather than "the argument was ignored".
This is the write-side counterpart to #1531, where graph_name is accepted but clobbered for two query types.
Related, same shape
api/router.py:99-101 discards branch, repo_name and force from IndexRequest:
args = {"path": request.path} # repo_name/branch/force are not supported
IndexRequest.branch is declared at api/schemas.py:8, so the HTTP API advertises a field it drops. (Relevant to #736, which asks for per-branch indexes.)
Suggested fix
Either honour graph_name in the handler by routing the writer to db_manager.get_driver(graph_name), or remove it from the tool schema until it is implemented. Advertising an argument that is silently ignored is worse than not offering it — the same applies to the three discarded IndexRequest fields.
Environment
|
|
| Commit |
HEAD (0.5.4) |
| Python |
3.12.3, Linux |
Found during backlog triage while verifying #736. Verified by reading the schema against the handler.
tool_definitions.py:25declaresgraph_nameas an input toadd_code_to_graph:but the handler never reads it —
tools/handlers/indexing_handlers.py:12-21:Only
path,repo_pathandis_dependencyare consulted.graph_nameis silently discarded.Impact
FalkorDB is the default backend and is multi-graph —
list_graphsis an exposed tool (tool_definitions.py:386) and query handlers honourgraph_name(handlers/query_handlers.py:46). So an agent can legitimately do:and reasonably believe the repository landed in
service-a. It lands in the default graph instead, with no warning. A lateranalyze_code_relationships(..., graph_name="service-a")then finds nothing, and the failure looks like "indexing didn't work" rather than "the argument was ignored".This is the write-side counterpart to #1531, where
graph_nameis accepted but clobbered for two query types.Related, same shape
api/router.py:99-101discardsbranch,repo_nameandforcefromIndexRequest:IndexRequest.branchis declared atapi/schemas.py:8, so the HTTP API advertises a field it drops. (Relevant to #736, which asks for per-branch indexes.)Suggested fix
Either honour
graph_namein the handler by routing the writer todb_manager.get_driver(graph_name), or remove it from the tool schema until it is implemented. Advertising an argument that is silently ignored is worse than not offering it — the same applies to the three discardedIndexRequestfields.Environment
Found during backlog triage while verifying #736. Verified by reading the schema against the handler.