CALLS edges fall back to File/Module node when enclosing_func_qn is unset — trace_path returns empty (root cause for #694/#480/#686/#678/#523)

[lg320531124]

Summary

trace_path and call-graph queries return empty results across several unrelated reports, and I believe they share one root cause: when the LSP does not populate the enclosing-function qualified name for a call site, calls_find_source falls back to attaching the CALLS edge to the File/Module node instead of the enclosing function. Downstream traversal is by function node, so the edge is invisible to function-scoped queries.

Filing this as a consolidated root-cause issue rather than a sixth per-language symptom report.

Root cause (source-level)

src/pipeline/pass_calls.c:404-417 — calls_find_source():

/* Find source node for a call: enclosing function or file node. */
static const cbm_gbuf_node_t *calls_find_source(cbm_pipeline_ctx_t *ctx, const char *rel,
                                                const char *enclosing_qn) {
    const cbm_gbuf_node_t *src = NULL;
    if (enclosing_qn) {
        src = cbm_gbuf_find_by_qn(ctx->gbuf, enclosing_qn);   // 1. enclosing function
    }
    if (!src) {
        char *fqn = cbm_pipeline_fqn_compute(ctx->project_name, rel, "__file__");
        src = cbm_gbuf_find_by_qn(ctx->gbuf, fqn);            // 2. FALLBACK -> File node
        free(fqn);
    }
    return src;
}

resolve_single_call (line 424) calls this for the edge source. When call->enclosing_func_qn is unset or unresolvable, step 1 misses and step 2 attaches the CALLS edge to the file's __file__ node. The edge exists and is traversable via query_graph on the file node, but trace_path / search_graph scoped to a function see zero outbound CALLS — hence "returns empty despite traversable CALLS edges".

Why this hits specific languages hardest

LSP enclosing-function resolution is most likely to come back empty for:

• C/C++ — C/C++ CALLS edges are attributed to the File/Module, not the enclosing function — callers are file-level, callees are empty (Python is correct) #694 (CALLS attributed to File/Module); tests/test_c_lsp.c:593 carries the comment "Issue C++ CALLS edges attributed to Module node instead of Function/Method nodes #220: C++ CALLS edges were attributed to the Module (file) node", so this is a known historical recurrence.
• Cross-repo — Go services get 0 cross-repo edges (Fiber route paths empty, gRPC not captured) #686 (Go 0 cross-repo edges), cross-repo-intelligence: 0 edges for FastAPI backend — Route.path empty, router prefix stripped #678 (FastAPI 0 edges), cross-repo-intelligence returns 0 edges for a byte-identical call/route #523 (cross-repo 0 edges): LSP doesn't cross repo boundaries, so enclosing_func_qn is empty for cross-repo call sites and every such edge lands on the File node.
• Top-level / macro / dynamic call sites — trace_path returns empty for all functions despite traversable CALLS edges (v0.8.1, macOS arm64) #480 (trace_path empty for all functions on macOS arm64, polyglot repo).

Six reports, one mechanism.

What I checked before filing

• C/C++ CALLS edges are attributed to the File/Module, not the enclosing function — callers are file-level, callees are empty (Python is correct) #694 timeline: cross-referenced only to task issues task: Parsing & extraction quality — language/format coverage gaps #592 / task: Graph queries & trace_path resolution #594, no linked fix PR.
• Searched open issues for enclosing_func_qn / file-fallback framing — no duplicate root-cause issue.
• pass_calls.c commit history on main: recent fixes (cross-repo-intelligence returns 0 edges for a byte-identical call/route #523 sequential external, fix(pipeline): persist call-site line on CALLS edges #508 call-site line, Java/Go module-QN de-double) touch surrounding paths but not the enclosing -> __file__ fallback itself.

Fix direction (asking before coding)

Two honest options, I'd like a steer on which you prefer before opening a PR:

1. Stop falling back to File when enclosing_qn is set-but-unresolved — drop (or defer) the edge rather than misattribute. trace_path correctness improves for resolvable sites, but total CALLS edge count drops where the enclosing function genuinely can't be resolved.
2. Keep the File fallback but tag it — add a source_kind: "file_fallback" (or similar) prop on edges emitted from the fallback path, so function-scoped traversal can skip/flag them while the file-level graph stays intact. Additive, lower risk.

I lean toward (2) for a first PR since it doesn't reduce edge coverage, but (1) is cleaner if you'd rather not carry misattributed edges at all. Happy to implement either with a reproduce-first test.

Reproduce

A test that indexes a C/C++ or cross-repo call site where enclosing_func_qn is empty, then asserts trace_path on the enclosing function returns a non-empty path — RED on current main, GREEN after the fix. (I'll write this in the PR.)

[lg320531124]

Linking the per-language symptom reports that trace to this same fallback: #694 (C/C++), #480 (trace_path empty), #686 (Go cross-repo), #678 (FastAPI cross-repo), #523 (cross-repo), and the historical note in tests/test_c_lsp.c:593 referencing #220.

[DeusData]

Thanks for consolidating this root cause. Triage: high-priority call-graph correctness under #594/#592.

The File/Module fallback can be useful as provenance, but function-scoped traversal must not lose calls when enclosing_func_qn is missing. The fix should be driven by one focused fixture that proves a CALLS edge attaches to the right enclosing symbol, plus compatibility checks for the reports you linked (#694/#480/#686/#678/#523).

[rudi193-cmd]

Additional symptom class — Python import … as (production callers invisible)

Same user-facing failure as the File/Module fallback (empty or wrong inbound set), but enclosing_func_qn is set — the miss is import-alias resolution.

Public repro: willow-2.0 willow/fylgja/events/pre_tool.py:

from willow.fylgja.safety.security_scan import (
    scan_bash as _scan_bash,
    ...
)
...
issues = _scan_bash(command)   # production PreToolUse path

trace_path(scan_bash, inbound) → only kart_task_scan test-path callers; no pre_tool.py production site.

This nearly shipped as “scanner has zero production callers” in our Kart security audit — grep recovered the alias calls.

Filed separately as #875 (Python-specific). Suggest linking under this root-cause hub alongside #694/#871 — three mechanisms, one audit lesson: never trust inbound CALLS without grep/source confirmation.

[lg320531124]

Thanks @rudi193-cmd — the import … as alias blind spot is a genuinely distinct mechanism from the File/Module fallback (enclosing_func_qn set vs. unset), good catch. Linked #875 alongside the other per-language symptoms in the hub. The shared audit lesson — "never trust inbound CALLS without grep/source confirmation" — is now documented across #694 (C/C++), #871 (CommonJS require), #480, #686 (Go), #678 (FastAPI), #523, and #875 (Python aliases).