Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Bug]: MCP query_graph and shortest_path rebuild a copy of the whole graph on every call

クローズ
  • 何か問題がありますか？
#4,191 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

  • #4192 @rohit-jsfreaky による — マージされずにクローズ

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
python
領域
performance

調査の方向性

Read graphify/serve.py: _traversal_view(G) and _shortest_path_text, plus the trigram index caching pattern in _get_trigram_index(G) which stores state on G.graph and is invalidated by a hot reload. Done means each rebuilt structure is built once per loaded graph with byte-identical query answers, verified by the reproduction script in the issue. However, the reporter states a fix is ready and PR #4192 is already open against this issue, so it is not available as a first contribution.

索引モデルが issue の本文から書いたものです。

説明

bug
Pre-flight checks
  • I have checked the Troubleshooting section in the README
What happened?

On a warm MCP server, most of a query_graph call and nearly all of a shortest_path call is spent rebuilding a structure that is the same for every call on the same graph:

  • _query_graph_text calls _traversal_view(G), which copies every edge of the loaded DiGraph into a new undirected graph on every query (~38k add_edge per query on graphify's own graph).
  • _shortest_path_text builds a sorted nx.DiGraph (or nx.Graph with undirected=true) from every edge on every call (sorted for the deterministic route, #2074). The path search itself takes under 1 ms.

The _traversal_view docstring chose this on purpose ("A fresh copy per query rather than a cached one ... only the edge dicts are duplicated"), i.e. for memory/simplicity, not correctness. The trigram index already uses the safe alternative: build once and cache on G.graph, which a hot reload invalidates by swapping in a new graph object.

Expected: build each structure once per loaded graph; answers unchanged.

Steps to reproduce
# graphify's own repo, built graph (18,865 nodes / 38,458 edges)
python - <<'EOF'
import time, statistics, graphify.serve as S
G = S._load_graph("graphify-out/graph.json"); S._get_trigram_index(G)   # what the server does at load
t=[]
for _ in range(10):
    s=time.perf_counter(); S._shortest_path_text(G, {"source": "load_cached", "target": "save_cached"}); t.append(time.perf_counter()-s)
print("shortest_path median ms", statistics.median(t)*1000)
EOF
# profile: almost all time is building the sorted DiGraph; nx.shortest_path on it is < 1 ms.
# same for query_graph: ~half the call is _traversal_view copying every edge.
Error output or graph output
shortest_path: ~93 ms of a ~108 ms call is building the sorted DiGraph; nx.shortest_path on it: 0.24 ms
query_graph: _traversal_view = ~half of a warm call (406,495 add_edge calls over 10 queries)

Warm-server medians on graphify's own graph (v8 f765dcb): query_graph 270-430 ms, shortest_path 100-235 ms (laptop, varies with thermal state).
Graphify version

0.9.79 (f765dcb)

Operating System

Windows

Python Version

3.12

Installation Method

built from source (git clone)

Additional Environment Details

No provider keys set. Measured in-process on the MCP code path (_load_graph + _query_graph_text / _shortest_path_text).

Additional context

A fix with before/after numbers and identical-output checks is ready; PR right after this.

主要言語
Python
スター
124k
フォーク
11.9k
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Graphify-Labs/graphify のほかの issue

Graphify-Labs/graphify の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。