Python: aliased module imports (`import x as y`, `from p import x as y`) still produce zero call edges — remaining gap after #578 / #715

[JoeyNPP]

Summary

#578 (module-attribute call sites after from pkg import module) was fixed by #715 and the plain form now resolves correctly. But the aliased forms still produce no calls edges on 1.6.0 (latest, npm). The call lands in unresolved_refs with status='failed' and the caller is silently absent from codegraph_callers and from the MCP codegraph_explore blast-radius summary.

Repro (1.6.0, win32-x64, Python project)

# services/kit.py
def sync_subscribers(get_db):
    ...

# routes/email.py
from services import kit as kit_service        # <-- aliased from-import

def handler():
    kit_service.sync_subscribers(get_db)       # no calls edge

# hook.py
import build_api_contract as builder           # <-- aliased plain import

builder.source_fingerprint()                   # no calls edge

Observed on a real repo (side-by-side in the same index, same session):

Import form	calls edge created?
from services import email_send -> email_send.log_sent()	yes (fixed by #715)
from services import leads as leads_svc -> leads_svc.convert_lead_to_buyer()	no
import build_api_contract as builder -> builder.source_fingerprint()	no

Module-level vs function-scoped import makes no difference — both aliased forms miss.

unresolved_refs rows for the failing sites look like:

('builder.source_fingerprint', 'calls', 'failed')
('kit_service.sync_subscribers', 'calls', 'failed')

Why it bites

Same consequence as #578: codegraph_callers reports a function as having one caller (a script) when a live route handler also calls it through the alias — "is this dead code?" gets the wrong answer. The MCP codegraph_explore output is also self-inconsistent in this case: the blast-radius header says "1 caller in scripts/kit_sync.py" while the verbatim source it prints below shows the aliased call site.

Suggested fix

Wherever #715 taught the Python resolver that a bare imported-module name qualifies attribute calls, the alias table needs to participate: import x as y / from p import x as y should register y as a binding for module x in the same scope map.

[maxmilian]

#1635 fixes the from-import half. Your diagnosis pointed at the right place: resolvePythonModuleMember rebuilds the submodule's dotted path from the local name, so from services import kit as kit_service had it looking for services.kit_service — a module that doesn't exist — and the call fell through to unresolved_refs. Joining with the exported name instead resolves it; unaliased imports are unaffected since the two names coincide there.

On the second half, I have to report a difference rather than a fix. import build_api_contract as builder resolves on current main in my reproduction. That form is a namespace import and binds at source — the real module name — so it never goes through the join that broke the aliased from-import.

I checked instead of assuming: with the resolver change reverted, a probe on the plain-aliased call site still reports its one calls edge. My fixture is a root-level top_level.py beside the caller, which is the shape your hook.py / build_api_contract.py example describes.

So if you're still seeing that one fail on the real repo, something else is in play — and it would be useful to know what. Two things that would narrow it fast:

• is build_api_contract.py actually in the index? (codegraph_search for source_fingerprint, or check fileCount against the tree)
• is the call site inside a function, or at module level in a conditional/try block?

Happy to take that half too once there's something reproducible. Either way it seems worth keeping this issue open until the plain-import case is settled — #1635 only closes the aliased from-import.