Repository navigation
Bug in Python parsing, class/static methods not added as CALLS edges #228
Description
Try to index the attached example, is not able to find the methods and it results in false positives as dead code.
build_from_text build_from_mapping are not indexed, in degree 0, out degree 0
"""Module demonstrating direct class usage — baseline case."""
from core.schemas import ActionRecordX
def run_plain_flow():
"""Invokes constructor helper without aliasing."""
return ActionRecordX.build_from_text("hello")
def adapt_plain_flow():
"""Invokes alternate constructor without aliasing."""
return ActionRecordX.build_from_mapping({"label": "world"})
"""Module demonstrating aliased import — alias resolution case."""
from core.schemas import ActionRecordX as ActionAlias
def run_alias_flow():
"""Invokes constructor helper via alias."""
return ActionAlias.build_from_text("hello")
def adapt_alias_flow():
"""Invokes alternate constructor via alias."""
return ActionAlias.build_from_mapping({"label": "world"})
from pydantic import BaseModel
class ActionRecordX(BaseModel):
label: str
@classmethod
def build_from_text(cls, raw: str) -> "ActionRecordX":
return cls(label=raw)
@classmethod
def build_from_mapping(cls, payload: dict) -> "ActionRecordX":
return cls(label=payload["label"])
Activity
DeusData commentedon Apr 10, 2026
Hey, thanks for noticing. Will tackle this once I am back on the 15th :)
CDreselerGSD commentedon Apr 30, 2026
We see a related symptom in the same codepath: not just missing CALLS edges, but the entire method nodes are absent from the index for
@staticmethod,@classmethod, and@propertymethods.Repro on a Python project with codebase-memory-mcp v0.6.0:
_get_running_worktree_paths_detect_repo_rootfrom_envprofile_namesPlain instance methods on the same classes ARE indexed. After
graph.reindex(11910 → 13700 nodes) the bug persists, so it is not a stale-index issue.Likely root cause: the tree-sitter Python extractor walks
function_definitionwithout descending throughdecorated_definitionwrappers — so decorated methods never reach the node-creation pass, which then makes #228's edges-missing case inevitable too.Both symptoms (missing nodes / missing edges) probably share the fix in the extractor's
decorated_definitiontraversal.DeusData commentedon May 31, 2026
Verified resolved on v0.7.0. The missing CALLS edge for
ActionRecordX.build_from_text(...)— a class/static method called directly on a cross-file imported class — is created correctly now; the py_lsp cross-file resolver was reworked since 0.6.0. I added a regression test (pylsp_crossfile_classmethod_on_class_issue228) that feeds your exact pattern (from core.schemas import ActionRecordX→ActionRecordX.build_from_text('hello')) through the resolver and asserts therun_plain_flow → build_from_textedge resolves (passes in the full suite, 3,629 tests).That removes the false "dead code" classification for those constructors. If you still see
build_from_text/build_from_mappingat in-degree 0 after a fresh full index on v0.7.0, please reopen with the two files (the caller +core/schemas.py) and I'll add an end-to-end repro. 🙏test(py-lsp): regression for DeusData#228 (cross-file classmethod on …
CDreselerGSD commentedon Jun 1, 2026
Confirming v0.7.0 fixes our broader symptom too — not just the original
classmethod edge case.
We hit a wider variant of this in production: any
@staticmethod,@classmethod, or@propertymethod was completely missing from the graph(zero nodes, not just dropped edges). The hybrid Light-Semantic-Pass in v0.7.0
resolves all four of our repro cases:
@staticmethod_get_running_worktree_paths@staticmethod_detect_repo_root@classmethodfrom_env@propertyprofile_namesVerified the v0.7.0 hits return real structured data, not stubs:
{ "name": "_detect_repo_root", "qualified_name": "srv-repos-XYZ.worktree.WorktreeManager._detect_repo_root", "label": "Method", "file_path": "XYZ/worktree.py", "start_line": 159, "end_line": 162 }Sanity checks alongside:
xyzzy_doesnt_exist_42→ 0 results ✅handle_search→ 6,handle_history→ 2,WorktreeManager(class) → 20 ✅So the tree-sitter
decorated_definitiontraversal fix in v0.7.0 generalizescorrectly — closes our use case as well. Thanks for the quick turnaround.