Go: `codegraph_callers` severely under-reports cross-package qualified calls (`pkg.Func(...)`) — <1% recall on a large Go monorepo

[wnzzer]

Summary

On a large Go monorepo (~4,260 .go files, 93k nodes, 256k edges, single language), codegraph_callers returns 0–2 callers for cross-package functions that grep finds hundreds to thousands of call sites for. In-package / unqualified call resolution works correctly.

This affects the central value proposition of the tool for Go projects — callers / impact / callees / trace all build on the same call edges. For a layered Go codebase (handler/ → service/ → domain/ → dao/ packages), where the vast majority of calls cross package boundaries, these tools effectively return empty results.

Environment

• @colbymchenry/codegraph@0.9.4 (npm-shim, darwin-arm64)
• macOS 24.6.0
• Project: Go monolith, 4,260 .go files (+4 yaml), single Go module
• Index status:
  • Files indexed: 4,264
  • Nodes: 93,703
  • Edges: 255,667
  • DB size: 177.47 MB
  • Journal mode: WAL
• Index is fresh (just ran codegraph init -i), no concurrent writes during query

Observed Behavior — Recall Numbers

All symbol names below are anonymized; pkgA is a high-fan-in utility package (logging/error helpers), pkgB is a configuration/rights package. The shapes are real, only names are scrubbed.

Symbol	Call form in source	Actual call sites (grep -rn)	codegraph_callers returned	Recall
pkgA.FuncX (e.g. error helper)	pkgA.FuncX(ctx, ...) (qualified, cross-package)	5,303	1	~0.02%
pkgA.FuncY (e.g. info helper)	pkgA.FuncY(ctx, ...) (qualified, cross-package)	603+ files	2	<0.5%
pkgB.FuncM	qualified cross-package	2	0	0%
pkgB.FuncN	qualified cross-package	4	0	0%
ok (in-package helper, multiple defs)	bare call, same file	n/a (aggregated query)	3 returned + 10-symbol aggregation note ✅	works

Querying with or without the package prefix in the symbol argument both fail equivalently:

• codegraph_callers symbol="FuncY" → No callers found
• codegraph_callers symbol="pkgA.FuncY" → 2 callers (vs 600+ actual)
• codegraph_callers symbol="pkgB.FuncM" → No callers found

What Works vs What Doesn't

Tool	Verdict
codegraph_search (find symbol by name)	✅ works, fast
codegraph_node (signature/source)	✅ works
codegraph_context (related symbols)	🟡 partial — relies on edges, "related symbols" list quality degrades
codegraph_files	✅ works
codegraph_callers	❌ <1% recall on cross-pkg
codegraph_callees	❌ same root cause
codegraph_impact	❌ same root cause
codegraph_trace	❌ same root cause

So definition-lookup is solid; the call-graph layer — the headline feature — is unusable on this codebase.

Reproduction Pattern

Any Go project with this shape will likely repro:

project/
  pkg_a/
    foo.go        // package pkg_a; func Foo() {}
  pkg_b/
    bar.go        // package pkg_b; import ".../pkg_a"; func Bar() { pkg_a.Foo() }
  pkg_c/
    baz.go        // package pkg_c; import ".../pkg_a"; func Baz() { pkg_a.Foo() }

Expected: codegraph_callers Foo (or pkg_a.Foo) returns 2 callers.
Observed (on a 4k-file repo at least): 0 or 1, not 2.

I haven't built a minimal repro repo yet — happy to do so if it would help. The pattern above plus several hundred unrelated packages may be needed to trigger whatever the actual failure mode is (a tiny 3-file repro may resolve fine).

Hypothesis / Pseudocode

I haven't read src/resolution/import-resolver.ts end-to-end, but from #314's description ("import-resolver.ts handles import parsing for TypeScript/JavaScript, Python, Go, and PHP"), the Go branch exists. So this isn't "Go has no resolver" — it's "the Go resolver / edge writer drops the vast majority of cross-package edges silently."

Possible failure modes (pseudocode):

// In Go resolution, for a call expression `pkg.Func(args)`:
function resolveGoQualifiedCall(callExpr, fileImports) {
  const pkgAlias = callExpr.qualifier   // e.g. "pkgA"
  const funcName = callExpr.name        // e.g. "FuncX"

  // Failure mode candidates:

  // (A) pkg alias not found in import mapping because Go's
  //     import resolver only handles imports declared *without* alias,
  //     or only handles `import "path"` not `import name "path"`.
  const importPath = fileImports[pkgAlias]
  if (!importPath) return null   // <- silently drops the edge

  // (B) importPath resolved but findExportedSymbol() can't locate
  //     the target node because the function's qualified_name in the
  //     DB is stored as bare `FuncX`, not `pkgA.FuncX`, and the
  //     lookup uses the qualified form
  const targetNode = findExportedSymbol(importPath, funcName)
  if (!targetNode) return null   // <- silently drops

  // (C) Edge is inserted but writes are batched and some batches
  //     are lost on indexer shutdown / SQLite contention (less likely
  //     given consistency of ~0% recall, not random partial recall)

  insertCallEdge(callerNode, targetNode)
}

(A) or (B) feels most likely given the cleanliness of the failure (~0 returned, not "some returned, some not"). A small fraction do get edges — possibly intra-module same-directory paths the path-proximity heuristic in findBestMatch (referenced in #314) happens to resolve.

Asks

1. Can the maintainer confirm whether the Go resolver currently relies on path-proximity matching (findBestMatch) rather than Go import declarations, or if there's an explicit extractGoImports branch?
2. If the latter, is there a known limitation around module-qualified imports (import alias "path", dot imports, blank imports, vendored deps) that drops the edge?
3. Happy to run targeted queries against my local index (.codegraph/codegraph.db SQLite) to validate hypotheses if useful — e.g., dump edges table grouped by source/target package to confirm whether cross-package edges exist at all.

Related Issues

• feat: Add Java import resolution to extractImportMappings for cross-module disambiguation #314 — Java: missing import resolver (different root cause, similar symptom)
• Python: cross-module function call resolution creates false cross-boundary edges #67 (closed) — Python: false-positive cross-module edges (opposite problem)
• TypeScript type alias members not used in method-call resolution → false cross-module calls edges via path-proximity #359 — TypeScript: false cross-module call edges via path proximity
• C# extractor produces zero references edges — type annotations on parameters, return types, and fields are never extracted #381 — C#: zero references edges due to missing extraction

[JosefAschauer]

Confirming this is not Go-specific — same root cause reproduces in Python with module-attribute access.

Python repro

api/db/services/dialog_service.py

def _shim(x):
return x

test/unit_test/api/db/services/test_shim.py

import api.db.services.dialog_service as dialog_service

def test_shim():
assert dialog_service._shim(1) == 1

codegraph_callers("_shim") returns no callers, even though the test clearly invokes the function via dialog_service._shim(...). The test is reaching the function by attribute access on the module object, not by a bare-name call after from ... import _shim.

Real-world impact

In a production codebase I'm working in (RAGFlow), a function _repair_grounded_citation_alignment defined on dialog_service has 9 regression tests that call it via dialog_service._repair_grounded_citation_alignment(...). codegraph_callers reports zero callers, which led
me to believe the function was dead code. Only a textual grep across the test directory revealed the real consumers.

The pattern is common in any Python codebase that:

• Uses module-level imports (import x instead of from x import y)
• Tests call internal helpers via the module attribute (x.y(...)) for ergonomic mocking / namespacing
• Re-exports symbols by attribute access on aggregator modules

Severity

Same shape as the Go report (pkg.Func(...)) — qualified calls aren't producing call edges. Affects any language that supports qualified call syntax (Python, Go, TypeScript namespaced exports, etc.). For users relying on codegraph_callers for "is this dead?" decisions,
this is a high-recall miss that can lead to incorrect dead-code deletion.

Workaround we're using

Fallback to a textual grep for qualified call patterns when codegraph_callers returns empty:

codegraph_callers --symbol Foo

If empty, also run:

grep -rn 'Foo\b' --include='.py' --include='.ts'

This catches attribute-access call sites that aren't yet in the call-graph edges.

[TheKenS]

This is not unique to Go. My React + TypeScript project has also encountered this issue.

Minimum Reversible Scene:

import type { IPage } from '../PageList';

interface Iprops {
  value?: Partial<IPage>;
}

The property_signature "Ipage" has not been processed by the extractor.

I'm not sure if there are any other similar cases that have not been dealt with.

fix pr: fix mine: #432

[colbymchenry]

Landed in #469 (squash-merged to main as f1b79ee).

Root cause confirmed — exactly the (A) hypothesis from your write-up. isExternalImport had no module-path awareness for Go, so every non-/internal/ import was flagged third-party, resolveViaImport returned null, and resolution fell through to name-matching with path proximity — which on a layered handler/service/domain/dao monorepo picks ~one accidental candidate per qualified call site.

Fix:

• New src/resolution/go-module.ts parses the module ... directive from project-root go.mod and exposes it on the resolver context.
• isExternalImport(go) treats <module-path>/... imports as in-module; the existing /internal/ escape hatch is preserved.
• resolveViaImport has a Go cross-package branch that strips the module prefix to a project-relative directory, then resolves the qualified member via getNodesByName(member) filtered to that exact directory and isExported=true. Sub-packages don't collide with parents; same-name funcs in different packages no longer false-merge.
• Side fix: Go nodes now correctly carry is_exported=1 for capitalized identifiers (the resolver needs this flag to filter candidates).

Measured on gRPC-Go (1,031 .go files, layered packages):

Metric	Before	After	Δ
Total calls edges	23,803	34,105	+43%
Cross-package calls	10,880	19,929	+83%
stdlib false-resolves (fmt.* etc.)	0	0	clean

CHANGELOG entry under [Unreleased] → Fixed; will ship in the next release.

If you can re-index the 4,260-file monorepo you reported on and the recall numbers move proportionally, that would close the loop on the original report.

[JosefAschauer]

Thanks for the fix but I assume this fixes only the go specific problem. As I wrote here: #388 (comment) This is not only go which is affected Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Colby Mchenry ***@***.***> Sent: Wednesday, May 27, 2026 12:46:36 AM To: colbymchenry/codegraph ***@***.***> Cc: Josh ***@***.***>; Comment ***@***.***> Subject: Re: [colbymchenry/codegraph] Go: `codegraph_callers` severely under-reports cross-package qualified calls (`pkg.Func(...)`) — <1% recall on a large Go monorepo (Issue #388) [https://avatars.githubusercontent.com/u/18431132?s=20&v=4]colbymchenry left a comment (colbymchenry/codegraph#388)<#388 (comment)> Landed in #469<#469> (squash-merged to main as f1b79ee). Root cause confirmed — exactly the (A) hypothesis from your write-up. isExternalImport had no module-path awareness for Go, so every non-/internal/ import was flagged third-party, resolveViaImport returned null, and resolution fell through to name-matching with path proximity — which on a layered handler/service/domain/dao monorepo picks ~one accidental candidate per qualified call site. Fix: * New src/resolution/go-module.ts parses the module ... directive from project-root go.mod and exposes it on the resolver context. * isExternalImport(go) treats <module-path>/... imports as in-module; the existing /internal/ escape hatch is preserved. * resolveViaImport has a Go cross-package branch that strips the module prefix to a project-relative directory, then resolves the qualified member via getNodesByName(member) filtered to that exact directory and isExported=true. Sub-packages don't collide with parents; same-name funcs in different packages no longer false-merge. * Side fix: Go nodes now correctly carry is_exported=1 for capitalized identifiers (the resolver needs this flag to filter candidates). Measured on gRPC-Go (1,031 .go files, layered packages): Metric Before After Δ Total calls edges 23,803 34,105 +43% Cross-package calls 10,880 19,929 +83% stdlib false-resolves (fmt.* etc.) 0 0 clean CHANGELOG entry under [Unreleased] → Fixed; will ship in the next release. If you can re-index the 4,260-file monorepo you reported on and the recall numbers move proportionally, that would close the loop on the original report. — Reply to this email directly, view it on GitHub<#388?email_source=notifications&email_token=AMBOXNF2KQI3KWJ2DS3LYTD44YNEZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJUHE3DKOBZGMYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4549658930>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMBOXNG3RS547YFRQRJMRWD44YNEZAVCNFSM6AAAAACZLUAIA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNBZGY2TQOJTGA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>