Python qualified class-method calls miss EXTRACTED edges

[noamsiegel]

Summary

On graphifyy v0.8.46, Python calls written as ClassName.method(...) do not produce an EXTRACTED calls edge from the calling method to the target class method, even when both methods are extracted with class-qualified node IDs.

This leaves impact/caller lookup incomplete for common Django/service-layer patterns such as a ViewSet action delegating to an action/service class.

Environment

• graphifyy: v0.8.46
• OS: macOS Darwin arm64
• Corpus: large Python/Django monorepo
• Graph: 233,713 nodes / 577,904 edges / 11,277 communities
• Built commit: 9e33b711243fb5b041e1500621430839c9da3303

Source shape

Caller in apps/hoa/api/admin_api/viewsets/customer_tasks.py:

class CustomerTaskAdminViewSet(...):
    @action(detail=True, methods=["post"])
    def approve_draft_with_charge(self, request, pk=None):
        ...
        result = CustomerTaskActions.approve_draft_with_charge(
            pk, request.data, request.user, task_file, charge_file
        )

Target in apps/hoa/api/actions/customer_task.py:

class CustomerTaskActions:
    @staticmethod
    def approve_draft_with_charge(pk, data, user, task_file=None, charge_file=None):
        ...
        charge_data = CustomerTaskActions._prepare_charge_data(data, approved_violation)

What Graphify extracts correctly

The target method now has a class-qualified node ID and method ownership:

graphify explain actions_customer_task_customertaskactions_approve_draft_with_charge --graph graphify-out/graph.json

Observed:

Node: .approve_draft_with_charge()
ID: actions_customer_task_customertaskactions_approve_draft_with_charge
Source: apps/hoa/api/actions/customer_task.py L970
Incoming: CustomerTaskActions --method [EXTRACTED]
Outgoing: ._prepare_charge_data() --calls [EXTRACTED]

The callee inside the same class is also correct:

graphify explain actions_customer_task_customertaskactions_prepare_charge_data --graph graphify-out/graph.json

Observed incoming callers include:

.approve_draft_with_charge() --calls [EXTRACTED]--> ._prepare_charge_data()
.save_charge_draft() --calls [EXTRACTED]--> ._prepare_charge_data()
.create_violation_task_with_charge() --calls [EXTRACTED]--> ._prepare_charge_data()

What is missing

The viewset action method is extracted, but its outgoing calls omit the qualified class-method call:

graphify explain viewsets_customer_tasks_customertaskadminviewset_approve_draft_with_charge --graph graphify-out/graph.json

Observed:

Node: .approve_draft_with_charge()
ID: viewsets_customer_tasks_customertaskadminviewset_approve_draft_with_charge
Source: apps/hoa/api/admin_api/viewsets/customer_tasks.py L986
Incoming: CustomerTaskAdminViewSet --method [EXTRACTED]
Outgoing: validate_file_size() --calls [EXTRACTED]

Expected an additional edge:

viewsets_customer_tasks_customertaskadminviewset_approve_draft_with_charge
  --calls [EXTRACTED]-->
actions_customer_task_customertaskactions_approve_draft_with_charge

Instead, graphify path can only bridge through an inferred class-level relationship:

graphify path viewsets_customer_tasks_customertaskadminviewset_approve_draft_with_charge actions_customer_task_customertaskactions_approve_draft_with_charge --graph graphify-out/graph.json

Observed:

.approve_draft_with_charge() <--method-- CustomerTaskAdminViewSet --uses [INFERRED]--> CustomerTaskActions --method--> .approve_draft_with_charge()

Expected

For Python code, a call expression of the form ClassName.method(...) should resolve to the extracted class-qualified method node when that class and method exist in the graph, producing an EXTRACTED calls edge from the enclosing caller method.

Related issues checked

• Member calls via injected fields (this.db.query()) do not produce class→dependency calls edges (TS/NestJS) #1316 covers TypeScript/NestJS injected-field member calls such as this.db.query() missing class-to-dependency calls edges.
• Go AST: cross-package qualified calls (pkg.Func()) never produce EXTRACTED edges #1313 covers Go cross-package qualified calls such as pkg.Func().
• AST: @property/@staticmethod methods get class-unqualified node ids but class-qualified rationale_for edge targets → docstring nodes orphaned at build #1050 fixed class-qualified IDs for decorated Python methods.

This issue is the Python qualified class-method-call equivalent: the IDs and method ownership now exist, but the ClassName.method(...) call edge is still missing.

[safishamsi]

Fixed on v8 (c390456). Root cause was two compounding things:

1. The shared cross-file pass skips all member calls (the Cross-file INFERRED calls resolution lacks import evidence + ambiguous-candidate handling — short common names blow up god_nodes ranking #543/Cross-file calls resolution drops EXTRACTED edges when the callee name has multiple definitions (even with unambiguous import evidence) #1219 god-node guard against bare obj.method() collisions), and there was no receiver-based resolver to recover the qualified ClassName.method() ones.
2. In the exact shape you hit — a viewset action approve_draft_with_charge() delegating to CustomerTaskActions.approve_draft_with_charge(...) — the called method shares its name with the caller, so the in-file bare-name lookup matched the caller's own node (tgt == caller) and the call was silently dropped before it ever reached cross-file resolution.

The extractor now captures the receiver, and a new resolver emits an EXTRACTED calls edge when ClassName resolves to exactly one class that owns the method (single-definition guard). self.x() / obj.x() instance calls are unaffected. Verified with your exact reproduction shape; full suite green. Thanks for the precise write-up — the class-qualified-ID detail and the related-issues list made this fast to pin down. 🙏