Cross-file `calls` resolution drops EXTRACTED edges when the callee name has multiple definitions (even with unambiguous import evidence)

[Alex-R-A]

Summary

When a called function name is defined in more than one file, the cross-file calls resolution drops the call edge entirely — even when the caller has an explicit, unambiguous named import that identifies exactly which definition is meant. With a single definition the edge resolves correctly (EXTRACTED). Adding any second same-named definition anywhere in the corpus removes the edge.

Net effect: silent false-negative calls edges. For any function whose name is defined 2+ times, call-edge recall is unreliable, and the absence of a calls edge cannot be trusted.

Version: graphify 0.8.35

Minimal reproduction

Three files in an empty directory:

helper.js

export function getThing() { return 1; }

duplicate.js

export function getThing() { return 2; }

caller.js

import { getThing } from './helper.js';
export function useThing() { const x = getThing(); return x; }

Run:

graphify extract . --no-cluster

Expected: a calls edge useThing -> getThing, bound to helper.js's getThing (the named import identifies it unambiguously).

Actual: useThing has no outgoing calls edge at all. Two getThing nodes exist (helper_getthing, duplicate_getthing) and neither lists useThing as a caller. The edge is dropped, not mis-bound.

Control (single definition works)

Delete duplicate.js and re-extract: the useThing -> getThing edge appears, EXTRACTED. Extraction and same-file binding are fine; the drop is triggered purely by the existence of a second same-named definition elsewhere.

Likely area

This looks related to the ambiguous-candidate handling introduced for #543 (which fixed the opposite problem: over-connecting INFERRED edges to every same-named node). That correctly stops over-connection, but a legitimate, import-evidenced EXTRACTED edge is now dropped when the name is multiply defined — the named-import evidence (from './helper.js') is not consulted to disambiguate in this JS/TS path.

Secondary observation: on a larger real corpus the behavior is also inconsistent across callers — with the same duplicate name present, some call sites keep the edge while others drop it, which makes the recall gap easy to miss.

Impact

• dependents / callers / impact / trace under-report for any multiply-defined name.
• A missing calls edge is a false negative, not evidence of "no call".

[Alex-R-A]

Root cause

It's in the cross-file call resolver inside extract() (graphify/extract.py, the for rc in all_raw_calls: loop, ~L11542 in 0.8.35). Unresolved callees are looked up in global_label_to_nids (name -> all matching node ids), then:

candidates = global_label_to_nids.get(callee.lower(), [])
# Skip ambiguous names that resolve to multiple nodes ...
if len(candidates) != 1:
    continue
tgt = candidates[0]

The len(candidates) != 1: continue guard (the #543 fix for short-name god-node inflation) runs before any import evidence is consulted. The import-evidence block right below it is only used to set confidence (EXTRACTED vs INFERRED) on an already-unique match. So when a name has 2+ definitions, the call is dropped even when the caller's import { foo } from './x.js' names exactly one of them. Net effect: silent false-negative calls edges for every multiply-defined name, and (on a real corpus) inconsistent recall across call sites.

Suggested fix

Consult import evidence before dropping: when there are multiple candidates, keep only those the caller actually imported (the symbol, or its module), and resolve only if that singles out exactly one. Zero or several evidenced candidates -> still skip, so the #543 guard for evidence-less short names is preserved.

candidates = global_label_to_nids.get(callee.lower(), [])
if not candidates:
    continue
caller = rc["caller_nid"]
caller_file_nid = nid_to_file_nid.get(caller)
imported_symbols = file_to_symbol_imports.get(caller_file_nid, set())
imported_modules = file_to_module_imports.get(caller_file_nid, set())
if len(candidates) == 1:
    tgt = candidates[0]
else:
    # Ambiguous name: disambiguate by import evidence (the caller imported
    # exactly one). Resolve only when evidence singles out one target; with
    # zero or several, skip (preserves the #543 god-node guard).
    evidenced = [
        c for c in candidates
        if c in imported_symbols
        or (nid_to_file_nid.get(c) is not None
            and nid_to_file_nid.get(c) in imported_modules)
    ]
    if len(evidenced) != 1:
        continue
    tgt = evidenced[0]
callee_file_nid = nid_to_file_nid.get(tgt)
has_import_evidence = (
    tgt in imported_symbols
    or (callee_file_nid is not None and callee_file_nid in imported_modules)
)
# ... unchanged: tgt != caller / existing_pairs guard, confidence, edge append

Verification

Applied locally against 0.8.35:

• Minimal repro from the issue: useThing -> getThing now resolves to helper.js's definition, EXTRACTED (bound to the imported one, not duplicate.js).
• A caller of the same ambiguous name without an import still gets no edge, so Cross-file INFERRED calls resolution lacks import evidence + ambiguous-candidate handling — short common names blow up god_nodes ranking #543's god-node behavior is unchanged.
• Full test suite: the confidence / symbol-resolution / extract / analyze (god-nodes) / build / languages suites all pass (454 in that subset; 1926 across the suite). The fix uses only locals already built in that function (file_to_symbol_imports, file_to_module_imports, nid_to_file_nid).

[safishamsi]

Fixed in HEAD (extract.py:11686-11705). The cross-file call-resolution loop now consults import evidence before bailing: (1) checks file_to_symbol_imports for a named import pointing to exactly one candidate — binds as EXTRACTED; (2) falls back to file_to_module_imports; (3) only skips if both fail. The over-connection guard for evidence-free common names is preserved. Smoke tests pass. Will be bumped in the next release.