Upgrade leaves stale state: save_manifest and --force both merge instead of replacing

オープン
#3,581 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python

調査の方向性

Trace the save_manifest path and the graphify update --force path, focusing on how manifest.json and graph.json are loaded and written. Reproduce the upgrade from project path A to path B, then verify that rewritten manifests and forced graph updates do not retain stale entries; check node and hyperedge counts and unresolved source_file paths.

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

説明

Summary

Upgrading in place from 0.5.4 → 0.9.62 leaves stale state behind in two separate places,
because both manifest.json and graph.json are merged into rather than replaced. The result
is a graph that keeps entries pointing at files that no longer exist at those paths, indefinitely,
with no warning.

The graph.json half is the more damaging of the two, and it survives --force.

1. save_manifest merges, so stale keys are never dropped

Before the upgrade, manifest.json held 38 keys, all absolute paths. After the upgrade wrote
new repo-relative keys, the file held 301 — the 263 new relative keys plus all 38 stale
absolute ones
. Nothing was removed.

So one file ends up describing the same tree twice, under two different key conventions, and the
stale half never expires.

Workaround: delete manifest.json before the first update. Doing so produced a clean
263 keys, 0 absolute, confirming the new code path is correct and only the merge is at fault.

2. graphify update --force merges graph.json too — this is the bigger one

--force reads as "discard and rebuild", and the guard message reinforces that reading:

WARNING: new graph has 4809 nodes but existing graph.json has 8473.
Refusing to overwrite — you may be missing chunk files from a previous session.
Pass --force to override.

It does not discard. Measured against a byte-identical backup of the pre-force graph.json:

count
nodes after --force 4809
of those, already present before 3708
newly created this run 1101
dropped 4765

Among the survivors, 219 nodes carry an absolute source_file under a directory the project was
checked out at previously and no longer is
. Zero of those 219 were newly created — every one
is a carry-over. They cannot be regenerated, because nothing exists at those paths now; they can
only persist.

Deleting manifest.json does not help here, because these live in graph.json.

Why this is worth fixing rather than documenting

  • The guard counts nodes only. On another repo in the same rollout the node count rose 61%
    while hyperedges fell 81% — the headline number hid the loss entirely. A merge that silently
    preserves unreachable nodes makes that harder to notice, not easier.
  • A tool that reports a knowledge graph of a codebase is expected to describe the current
    codebase. Nodes keyed to a path the code has not lived at for months are indistinguishable, to a
    consumer of graph.json, from live ones.
  • The only reliable remedy found was rm -rf of the whole output directory and a full rebuild,
    which also discards every LLM-derived rationale node — an expensive price for what reads like
    a cache-invalidation bug.

Reproduction

  1. On 0.5.4, build a graph for a project at path A.
  2. Move or re-clone the project to path B.
  3. Upgrade to 0.9.62.
  4. graphify update <B> → the guard refuses (fewer nodes without an LLM run, since rationale
    nodes cannot be reproduced).
  5. graphify update <B> --force.
  6. Inspect graph.json: nodes whose source_file still begins with path A are present, and
    none of them are new.

Expected

  • save_manifest replaces the manifest for the paths it rewrites, rather than unioning old and
    new key conventions.
  • --force replaces the graph, or the flag/message says plainly that it merges and that stale
    nodes are retained.
  • Ideally, nodes whose source_file no longer resolves are pruned on rebuild regardless of flag.

Environment

  • graphify 0.9.62 (upgraded in place from 0.5.4), installed as a uv tool
  • macOS, Python 3.14
  • Python project, ~160 source files, AST-only extraction (no LLM key configured at update time)
主要言語
Python
スター
124k
フォーク
11.9k
平均マージ
2時間 35分
マージ済み PR(30日)
6

環境構築

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

はじめの一歩

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

Graphify-Labs/graphify のほかの issue

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

似ている issue

Python の issue をもっと見る

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

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