# Bug: Same-named classes across modules silently overwrite each other in the graph

[aviciot]

Graphify version: 0.9.9

---

Hey team 👋

We're running Graphify on a large multi-module Maven project (15 modules, ~700 Java files) and hit a frustrating silent bug,

What happened

We have two completely separate classes both named FinancialEntryValidator — one in payment-adaptor and one in core-adaptor. Different packages, different logic, different purpose.

my-project/
  payment-adaptor/src/main/java/com/example/payment/service/FinancialEntryValidator.java
  core-adaptor/src/main/java/com/example/core/service/FinancialEntryValidator.java

When Graphify builds the graph, both get the same short node ID (financialentryvalidator). Since G.add_node() is idempotent, whichever gets processed last silently overwrites the other. The losing class completely disappears from the graph — no node, no edges, nothing.

There's no warning, no error, no indication anything went wrong.
The graph looks complete.- But when we asked our LLM "does the payment module validate currency against ISO 4217?" it answered confidently: no validation exists :(

The real answer is the opposite — the check is right there in the class that got overwritten:

// payment-adaptor - FinancialEntryValidator.java
private static final Set<String> ISO_CURRENCIES =
    Currency.getAvailableCurrencies().stream()
        .map(Currency::getCurrencyCode)
        .collect(Collectors.toSet());

if (!ISO_CURRENCIES.contains(currency)) {
    validationErrors.add("Currency [" + currency + "] is invalid ISO 4217 alpha-3 code");
}

Silent wrong answers are worse than no answers.

Minimal reproduction

import networkx as nx

G = nx.DiGraph()

# Module A processes first — real node with full source_file
G.add_node("financialentryvalidator",
    label="FinancialEntryValidator",
    source_file="payment-adaptor/.../FinancialEntryValidator.java"
)

# Module B processes second — stub node overwrites the real one
G.add_node("financialentryvalidator",
    label="FinancialEntryValidator",
    source_file=""   # stub — empty
)

# Real node is gone
print(G.nodes["financialentryvalidator"]["source_file"])  # "" — overwritten

What we did as a workaround

We added a post-processing step after build_merge that detects stub nodes (empty source_file) colliding with real nodes and redirects their edges to the correct real node. It resolved about half of the stubs in one repo .
But it can't resolve cases where multiple real classes share the same label — those stay broken and the LLM keeps getting wrong answers for those classes.

Same root cause — short names used as IDs without preserving module/package context. PR #1697 addresses call edge ambiguity for same-name methods.
This issue is about node identity — the class itself disappearing. Both need fixing, but they're separate problems.

Suggested fix direction

Node IDs for real classes (those with a known source_file) should incorporate the module/package path, not just the short class name. For example:

# Current — collision
financialentryvalidator

# Better — unique per module
payment_adaptor.financialentryvalidator
core_adaptor.financialentryvalidator

Stub nodes (import references with no source_file) can keep short IDs since they're placeholders anyway — and would correctly resolve to the right real node once IDs are unique.

let me know if more details or test a fix if that helps.

[safishamsi]

Fixed on v8 in ee1ff3d (shipping in 0.9.12). Thanks @aviciot for the precise root-cause and repro.

Two things, since the current state on v8 is a bit different from the 0.9.9 you tested:

The "node silently disappears" half is already fixed. Real class nodes now get path-scoped ids (e.g. payment_src_..._financialentryvalidator vs core_src_..._financialentryvalidator), so both same-named classes survive as distinct nodes with their own methods — add_node no longer collapses them. Your minimal repro (two add_node calls with the bare id financialentryvalidator) reflects the old id scheme; on v8 the extractor doesn't produce colliding ids for real classes anymore.

The residual you flagged is what this fix addresses. You were exactly right that the ambiguous case (multiple real classes sharing a label) stayed broken: a cross-module field/type reference was left dangling on a sourceless phantom stub. The machinery to fix it already existed — _resolve_java_type_references (#1318) re-points dangling edges to the real definition using the importing file's import statement for exact-package disambiguation — but its repoint set covered implements/inherits/imports and not references. Adding references (which the C# resolver already handled) makes a private FinancialEntryValidator validator field in a module that import com.example.payment.FinancialEntryValidator resolve to the payment class, not core, and drops the phantom.

On your repro shape: both classes present with their real methods, references lands on the imported (payment) class, zero sourceless phantoms. Regression test added.

Note this is import-driven: a reference with no import and a different package (relying on some other resolution) is left alone rather than guessed. If you have a case in your 15-module project where a same-named reference still lands wrong with a clear import, send the import line + the two package paths and I'll dig in. Closing as fixed for the import-disambiguated case.

[aviciot]

Hey @safishamsi - firts tnx for ur reply ,

wanted to follow up after testing the fix.

I'm on 0.9.9 against a 15-module Maven project (~700 Java files)-Upgraded to 0.9.12 from the v8 branch and re-indexed everything from scratch.

What I tested: the exact case from the bug report — two modules both containing FinancialEntryValidator, different packages, different logic.

What's fixed:
both classes now survive in the graph as distinct nodes with path-scoped IDs. Before, one was completely invisible and the LLM was confidently answering BS...

What's still off:

After the upgrade, module-a/FinancialEntryValidator ends up with methods from module-b/FinancialEntryValidator attached to it in the graph — so graphify is still cross-wiring edges between the two.
The node identity problem is solved but the edge resolution between same-named classes across modules still looks broken.
Could be related to the import-disambiguation piece — happy to share specific node IDs and package paths if useful.

Overall a clear improvement. Thanks!

[aviciot]

@safishamsi
One more data point after digging deeper.

The node identity fix works — both classes show up in the graph now. But the edges are still cross-wired. Concretely: the module-a/FinancialEntryValidator node ends up with module-b's methods attached to it (.validateAll(), .isCurrencyTooLong()).

The impact is real — asked the LLM "does the APM flow validate currency before sending to the bank?" and it answered: "basic format check only, no supported-currency whitelist check exists." The actual code has an explicit ISO 4217 whitelist check in that
exact class. The LLM found the right node but described the wrong methods because of the edge mix-up.

So the silent-disappearance is fixed, but same-named classes across modules are still sharing edges. Happy to share the raw node IDs if that helps track down where the cross-wiring happens