Recursion flags still false-positive on store/delegation calls after #599 (soil.get, _default.check)

[rudi193-cmd]

Summary

On v0.8.1, unguarded_recursion / self_recursive / recursive still flag functions that do not call themselves when the body calls a same-named method on another receiver (store delegation, module singleton delegation).

#599 (closed) addressed super().method() and axios.get-style cases. Store wrappers and _default.foo() delegation still false-positive.

Environment

• Binary: codebase-memory-mcp 0.8.1
• Project: home-sean-campbell-github-willow-2.0 — 14 nodes with unguarded_recursion=true

Reproduction

core.soil.get — flagged, not recursive

def get(collection: str, record_id: str) -> dict | None:
    rec = _get_store().get(collection, record_id)  # store.get, not self.get
    ...

Graph properties: unguarded_recursion=true, self_recursive=true, loop_count=0.

Same pattern on core.soil.put, delete, stats (_get_store().put etc.).

core.gleipnir.check — delegation false positive

def check(app_id: str, tool_name: str) -> tuple[bool, str]:
    return _default.check(app_id, tool_name)

Graph: unguarded_recursion=true, recursive=true.

willow.nuke.execute — recursive=true, no self-call

Body is loops + filesystem/Postgres I/O only; no call to execute itself. Yet recursive=true (and high transitive_loop_depth propagation).

Expected

Self-recursion only when the call resolves to the same function/method binding — not bare name match on a different receiver (store.get, _default.check, etc.).

Impact

Hot-path queries like WHERE f.unguarded_recursion = true surface noise; agents may treat load-bearing store wrappers as recursion hazards. Same bare-name resolver class as fan-in inflation (#725).

Relation to #599

#599 fixed several super() / cross-receiver patterns. This report is the remaining delegation/store bucket on v0.8.1 after that close.

Confirmations

• Searched issues; [bug] self_recursive / unguarded_recursion match calls by bare name → super().save() and same-named wrappers are false positives #599 is closest prior (closed).
• Public OSS reproduction (willow-2.0).

[DeusData]

Thanks for checking the #599 follow-up class. Triage: parsing false-positive under #592. The fix should distinguish direct self-recursion from same-named calls on another receiver, including store/delegation patterns like _get_store().get(...) and _default.check(...), with a regression that keeps the original real-recursion cases green.

[DeusData]

Good news: this bucket is fixed on v0.9.0. The receiver-aware narrowing you referenced from #599 (commit 87091ed, released 2026-07-08 in v0.9.0) also covers the delegation/store patterns — your v0.8.1 binary predates it.

Verified against current main with your exact three shapes:

Pattern	recursive	self_recursive	unguarded_recursion
_get_store().get(...) inside def get (soil)	0	0	0
_default.check(...) inside def check (gleipnir)	0	0	0
cur.execute(...) in a loop inside def execute (nuke)	0	0	0
control: genuine self-recursion	1	1	1

Since #599's tests didn't cover this specific bucket, #1047 adds a permanent regression guard with these three fixtures so it can't quietly come back.

Could you retest on v0.9.0 (npm i -g codebase-memory-mcp@latest or the GitHub release binaries) against willow-2.0 and confirm the 14 flagged nodes clear? If anything still false-positives there, please paste the remaining function bodies and we'll reopen the hunt.

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

[github-actions]

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.