Python: module-scope dict member calls can resolve to unrelated project methods #1652

Activity

1. inth3shadows commented on Sep 4, 2026

   

   inth3shadows

   on Sep 4, 2026

   Contributor

   More actions

   Tried to build a reproduction for this and could not on 1.6.0 (npm latest) — posting the attempt so it is not re-attempted blind, and so you can tell me what my fixture is missing.

   # pkg/api.py
   def get(k):    return k
   def update(d): return d

   # pkg/use.py
   CONFIG = {"a": 1}
   REG = dict()
   
   def reads(k):
       return CONFIG.get(k)              # module-scope dict member  -> no edge
   
   def writes(d):
       REG.update(d)                     # module-scope dict member  -> no edge
   
   def chained(m, k, v):
       return m.setdefault(k, {}).get(v) # -> calls pkg/api.py:get   FABRICATED

   Result on a fresh index: the two module-scope dict calls produce no edges at all (correct), while the third line fabricates exact-match -> api.get.

   So with a plain {...} / dict() module-scope binding and a same-named top-level function present, I do not see the misresolution this issue describes. What I do see is that the receiver shape decides it: a plain identifier receiver is filtered correctly, a call-expression receiver is not.

   Two possibilities:

   1. Your case involves a receiver that is not a plain identifier (a subscript, an attribute chain, a call result), in which case it is the same root cause as Call-expression receivers drop the receiver and fabricate a calls edge to any same-named top-level symbol — Python AND JavaScript, live in 1.6.0 #1683 and would be closed by the same fix.
   2. It needs something my fixture lacks — the dict built by a comprehension or a function call, a TypedDict/annotation, or a call through an import rather than same-file.

   If you can share the receiver expression and how the dict is bound, I am happy to re-run it. Details that would pin it: the exact call line, how the dict is created, and whether the wrongly-resolved target is a module-level function or a class method.

   Environment: 1.6.0 (also checked 1.5.0), Linux, fresh codegraph init, verified via both the CLI and direct SQL against .codegraph/codegraph.db.
2. colbymchenry commented on Sep 8, 2026

   

   colbymchenry

   on Sep 8, 2026

   Owner

   More actions

   Fixed in #1776.

   DEFAULTS.get(name) (and other module-scope dict/list/set/tuple/frozenset member calls) no longer fabricate calls edges onto unrelated project methods such as LRUCache.get.

   Root cause: the Python builtin-method filter treated any symbol in knownNames as a “known class,” so the variable DEFAULTS itself escaped the filter; matchMethodCall Strategy 3 then single-survivor-bound the only get method in the project.

   Fix: decline when the receiver is a same-file module-scope collection binding (signature gate), and require an actual Python class/struct/interface for the class escape. Imported project-module calls (ledger.append, #1681) stay resolvable.

   Verified on Linux against the issue fixture (callers get → empty) and a 15-case regression suite (fail→pass vs main).
3. colbymchenry

   closed this as completedon Sep 8, 2026
4. colbymchenry

   added a commit that references this issue on Sep 8, 2026

   fix(resolution): reject Python module collection method guesses (#1652)…

   ...

   195888d
5. bompus

   added a commit that references this issue on Sep 8, 2026

   Merge origin/main (8c04734) into fork/consolidated

   ...

   20ded7c