Feature: build_merge dry-run, god-node degree-drop alert, and pre-write backup

[Ns2384-star]

Version: graphifyy 0.9.5.

Problem

build_merge writes graph.json with no preview and no backup. The shrink guard (#479) protects against global shrinkage, but not against local destruction of a hub: the graph can grow overall while a god node drops to 0 edges (lived: a 174-edge hub wiped by replace-on-re-extract after an entity-ID mismatch — total node count went up that run).

Proposal

1. build_merge(dry_run=True) → report of what would be pruned/replaced (nodes, edges, per-source counts) without writing.
2. Post-merge automatic alert when any node with ≥N edges loses >50% of its degree.
3. Automatic backup of graph.json before write (a single rolling copy is enough).

We've implemented (2) and (3) as a wrapper script around every update; they feel like they belong in the tool. Related: #834 (dated-folder backup, closed).

[AbarnaaSree]

Hi @Ns2384-star,

I would like to contribute to this issue.

I am interested in implementing the remaining build_merge safety improvements, especially:

1. build_merge(dry_run=True) support to generate a preview report without modifying graph.json
2. Automatic backup of graph.json before writing changes

I noticed that the hub-node degree collapse warning appears to have progress through #1661, so I would focus on the remaining parts.

My implementation plan:

• Inspect the existing build_merge pipeline and identify the graph write stage.
• Add a dry_run option that:
  • computes nodes/edges that would be added, removed, or replaced
  • reports affected sources
  • skips writing graph.json
• Add a pre-write backup step:
  • create a rolling backup of the existing graph.json
  • write the new graph only after backup succeeds
• Add focused tests covering:
  • dry-run does not modify files
  • backup is created before write
  • existing merge behavior remains unchanged

Could you confirm:

1. Is the remaining scope still available?
2. Which branch should I target (main or development branch)?
3. Are there existing conventions for merge reports/backups that I should follow?

Thanks!

[AbarnaaSree]

Hi @Ns2384-star,

Just following up on my previous comment. I've been reviewing the related implementation and issues (#1661, #1711, and #834) to better understand the merge pipeline and the remaining work.

My current plan is to implement:

• build_merge(dry_run=True) to generate a preview report without modifying graph.json.
• A rolling backup of graph.json before writing changes.

Before I begin implementing, could you please confirm whether this remaining scope is still available and whether I should target the main branch?

Thanks! Looking forward to contributing.

[Ns2384-star]

Hi @AbarnaaSree — yes, from the reporter's side the remaining scope (dry-run preview + pre-write rolling backup) is still open and very welcome; the degree-collapse warning is tracked separately in #1661. Two field notes from the corpus that motivated this issue: (1) the dry-run report is most useful if it lists, per source file, the node/edge counts replaced vs. pruned, and flags any node ≥N edges that would lose most of its degree — that's exactly the failure we hit; (2) a single rolling backup generation would already cover our use case. Branch/conventions are the maintainer's call (@safishamsi). Thanks for picking this up!

[AbarnaaSree]

Hi @Ns2384-star,

I've implemented the requested build_merge dry-run support and the associated diagnostics, and I've opened a pull request for review:

PR #2155 – Improve build_merge safety and add dry-run diagnostics

The PR includes:

• build_merge(dry_run=True) preview mode
• Dry-run report for added/removed nodes and edges
• Source-level impact reporting
• Hub degree collapse warning
• Tests covering the new functionality and changed-file replacement

Thank you!