Changed-files incremental rebuild drops cross-file dependency edges (hook install / watch affected)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 30/100
Direzione di ricerca
Run the probe script from the issue against a copy of a TypeScript repo to confirm _rebuild_code drops edges. Then read _rebuild_code in graphify/watch.py — the function both hooks.py:141 and watch.py:1067 call with changed_paths — and compare its preserved-node path against the full rebuild (changed_paths=None) to find where cross-file import resolution is skipped. Done looks like lost == 0 and invented == 0 against a full rebuild of the same tree.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
The changed-files incremental rebuild (watch._rebuild_code(changed_paths=[...])) is not edge-equivalent to a full rebuild. It drops cross-file dependency edges — including edges belonging to files that were never touched — so dependency, dependent and impact queries under-report after an incremental refresh.
This is reachable from two shipped features, not just the internal API:
graphify hook install— the post-commit hook calls_rebuild_code(_root, changed_paths=changed, force=_force)(hooks.py:141)graphify watch <path>— calls_rebuild_code(..., changed_paths=merged, ...)(watch.py:1067)
So a repository using the git hooks or the watcher accumulates edge loss on every commit or save, silently. The query most affected is graphify affected "X", since it is reverse traversal over exactly the relations being lost.
graphify update is unaffected: it always calls _rebuild_code(watch_path, force=..., no_cluster=..., block_on_lock=True) with changed_paths left at None (cli.py:2151), i.e. a full corpus rebuild. That is likely why this has gone unnoticed — the CLI never exercises the incremental path.
Version: 0.9.47 (graphifyy 0.9.47), macOS, Python 3.14
How it was measured
The comparison that matters is incremental vs a full rebuild of the same working tree, not incremental vs the pre-edit graph. Comparing against the pre-edit graph only shows that the edited file changed, which is expected and correct.
Procedure, on a copy of a 491-file TypeScript/JavaScript repository (346 files indexed):
_rebuild_code(root, changed_paths=None)→ baseline- append one exported function to a single indexed file
_rebuild_code(root, changed_paths=[that_file])→ incremental result_rebuild_code(root, changed_paths=None, force=True)→ correct result for the same tree- diff the edge sets of (3) and (4)
Results
| Touched file | Edges missing vs full | …originating from untouched files |
|---|---|---|
web/components/Workspace.tsx |
286 | 259 |
web/app/layout.tsx |
262 | 261 |
web/emails/templates.tsx |
263 | 263 |
Relation breakdown for the Workspace.tsx case (286 total):
imports_from 258
imports 24
references 3
dynamic_import 1
Two details that should help localise the fix:
- Zero edges were invented. The incremental result is a strict subset of the full result. That points at a missing re-resolution pass rather than corruption, and suggests the fix is additive.
- The loss is dominated by edges whose
source_fileis not the file that changed. Cross-file import resolution looks like a whole-corpus pass that is not re-run for preserved nodes, so their outbound import edges are lost when the graph is reassembled.
Node counts stay almost exactly right (2307 → 2307 in one case, with the new symbol correctly present), which is why the problem is easy to miss: the graph looks healthy by node count and the edited file's own symbols are updated correctly.
Why this matters
The loss is one-directional — it only ever removes dependency edges. So affected and any dependency/dependent query answers "nothing depends on this" about code that does have dependents. For an impact-analysis tool that is the dangerous direction: a change author is told it is safe to change something that is not.
Performance context
The incremental path is genuinely valuable, which is why this seems worth fixing rather than removing:
| Duration | |
|---|---|
| Full rebuild | 3.93 s |
| Incremental, no files changed | 0.08 s (~49×, byte-identical graph, zero delta) |
| Incremental, one file changed | 1.34–1.46 s (~3×) |
The no-change case is exactly correct, so the preservation machinery itself works; it is specifically cross-file relationship re-resolution that is missing.
Expected
Either of:
- A changed-files rebuild that re-resolves cross-file relationships for preserved nodes, so the result is edge-equivalent to a full rebuild; or
- Documentation that
changed_pathsis not correctness-preserving for dependency analysis — in which casehook installandwatchshould probably warn, since they use it by default.
Additionally, it would be useful to expose a correctness-preserving changed-files update through the CLI (e.g. graphify update --changed <paths>), so downstream tools can use the fast path without depending on a private function.
Reproduction
Self-contained script, run with the installed venv's interpreter. It performs the four steps above and exits non-zero while the fast path is lossy:
graphify_incremental_probe.py
import collections, json, pathlib, sys, time
def _graph(out):
payload = json.loads(out.read_text(encoding="utf-8"))
nodes = {n["id"]: n for n in payload.get("nodes", [])}
links = {
(l["source"], l["target"], l.get("relation")): l
for l in payload.get("links", payload.get("edges", []))
}
return nodes, links
def main():
if len(sys.argv) != 3:
print("usage: probe.py <repo-copy> <relative/file.ts>")
return 2
from graphify.watch import _rebuild_code
root = pathlib.Path(sys.argv[1]).resolve()
target = root / sys.argv[2]
out = root / "graphify-out" / "graph.json"
t = time.perf_counter()
_rebuild_code(root, changed_paths=None, no_cluster=True)
baseline = time.perf_counter() - t
bn, bl = _graph(out)
print(f"1. full baseline {baseline:6.2f}s nodes={len(bn)} edges={len(bl)}")
original = target.read_text(encoding="utf-8")
try:
target.write_text(original + "\n\nexport function __probe() { return 42; }\n",
encoding="utf-8")
t = time.perf_counter()
_rebuild_code(root, changed_paths=[target], no_cluster=True)
inc = time.perf_counter() - t
in_n, in_l = _graph(out)
print(f"2. changed-files {inc:6.2f}s nodes={len(in_n)} edges={len(in_l)}")
t = time.perf_counter()
_rebuild_code(root, changed_paths=None, no_cluster=True, force=True)
full = time.perf_counter() - t
fu_n, fu_l = _graph(out)
print(f"3. full, same tree {full:6.2f}s nodes={len(fu_n)} edges={len(fu_l)}")
finally:
target.write_text(original, encoding="utf-8")
lost = {k: v for k, v in fu_l.items() if k not in in_l}
invented = {k for k in in_l if k not in fu_l}
touched = str(target.relative_to(root)).replace("\\", "/")
from_touched = sum(1 for v in lost.values() if v.get("source_file") == touched)
print(f"\nspeedup {full / inc:.1f}x")
print(f"edges LOST by the fast path : {len(lost)}")
print(f" from the touched file : {from_touched}")
print(f" from untouched files : {len(lost) - from_touched}")
print(f"edges INVENTED : {len(invented)}")
print(" by relation:",
collections.Counter(v.get("relation") for v in lost.values()).most_common(6))
return 1 if lost else 0
if __name__ == "__main__":
raise SystemExit(main())
Run as:
<venv>/bin/python graphify_incremental_probe.py /path/to/repo-copy web/components/Workspace.tsx
Use a copy — it rewrites the named file and rebuilds graphify-out/ in place.
Sample output:
1. full baseline 4.24s nodes=2307 edges=5072
2. changed-files 1.46s nodes=2307 edges=4787
3. full, same tree 4.55s nodes=2308 edges=5073
speedup 3.1x
edges LOST by the fast path : 286
from the touched file : 27
from untouched files : 259
edges INVENTED : 0
by relation: [('imports_from', 258), ('imports', 24), ('references', 3), ('dynamic_import', 1)]
Happy to test a patch against the same repository if that would help.
- Lingua principale
- Python
- Stelle
- 124k
- Fork
- 11.9k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Graphify-Labs/graphify
-
[Bug]: `graphify export svg` writes a graph.svg that is not well-formed XML when a label contains a control characterForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Graphify-Labs/graphify#4241 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
Graphify-Labs/graphify#3763 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
Graphify-Labs/graphify#3611 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Nix supportAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
Graphify-Labs/graphify#3193 · 2 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
Graphify-Labs/graphify#2871 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Graphify-Labs/graphify
Issue simili
-
first
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
AcademySoftwareFoundation/rmtc#54 · 1 commento ·
-
feature/cohorts feature/feature-flags team/feature-flags
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
License examples/ as MITForse già presa @PGrayCS l’ha presa oggi. Apertadocumentation enhancement example good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
speedyk-005/yasbd-lib#383 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
interactions-py/interactions.py#1827 ·
-
Managed start can fail when OpenVMM reads its control capability before NVX writes itForse già presa @ppenna l’ha presa oggi. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno