Back Home

GitHub Repo

Graphify 0.9.66 pins hash seeds to reduce drift in rebuilt code graphs

The new release pins the hash seed used in graph processing and prioritizes directly extracted relationships over inferred results. The patch helps teams compare rebuilds, but model-generated content and consistency across versions still require separate verification.

CC BY-SA 2.5 · Image source
zh-Hant

Graphify released version 0.9.66 on September 22, pinning the Python hash seed for several commands to address cases where rebuilding a graph from the same code could still produce different results. The release also adjusts the rules for merging duplicate relationships, giving directly extracted evidence priority over inferred results. [Release notes](https://github.com/Graphify-Labs/graphify/releases/tag/v0.9.66)

Graphify parses code into nodes and relationships, such as calls and imports, then provides coding agents with queries, path tracing, and subgraphs. Code parsing runs primarily locally, while semantic processing of documents and media may invoke models. The conditions for reproducing structural parsing and model-generated content therefore need to be considered separately. [Project overview](https://github.com/Graphify-Labs/graphify)

The patch covers `update`, `extract`, `cluster-only`, and `label`: it sets `PYTHONHASHSEED` through a one-time process restart to reduce the hash seed’s influence on Leiden and Louvain community detection and align rebuilds triggered by manual commands and Git hooks. [Release notes](https://github.com/Graphify-Labs/graphify/releases/tag/v0.9.66) Python’s official documentation states that a fixed seed makes hash values reproducible for the affected types. This also explains why fixing only the clustering algorithm’s random parameters may not cover the entire data processing pipeline. [Python documentation](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED)

Relationship merging no longer depends solely on arrival order. When the same relationship has conflicting entries, the new release prioritizes `EXTRACTED` over `INFERRED`. These labels describe the source of the evidence and should not be treated as calibrated probabilities of correctness. For engineering teams, traceability helps identify which relationship an agent used, but verification against the source code remains necessary. [Release notes](https://github.com/Graphify-Labs/graphify/releases/tag/v0.9.66)

Based on these mechanisms, teams that incorporate graphs into version control or continuous integration can expect fewer differences unrelated to code changes, making it easier for reviewers to identify newly introduced dependencies. If an agent receives different community boundaries each time, the context used for its task may also change. Rebuild consistency is therefore worth measuring alongside answer quality, with the graph used at the time retained for later investigation, rather than merely checking whether the graph-building command succeeded.

The official package, `graphifyy` 0.9.66, is now available on PyPI. Its release attestation points to the same `a5957aa` commit as the release notes, providing a way to verify the source of a deployment. [Package record](https://pypi.org/project/graphifyy/0.9.66/) When adopting the release, teams can hold inputs, package versions, and parser versions constant, compare nodes, edges, and communities across rebuilds, and then test agent retrieval results. These are verification recommendations: the release notes currently provide no data showing that the patch improves task success rates, and pinning the hash seed does not guarantee identical model-generated labels or outputs across versions.

Sources

  1. Graphify v0.9.66 發行公告
  2. graphifyy 0.9.66 套件與發行證明
  3. Graphify 專案與技術說明
  4. Python 命令列與環境變數:PYTHONHASHSEED