TL;DR: get_directory_tree returns a degenerate tree on repos whose File-kind nodes store absolute paths. Instead of the repo layout, you get one leaf node at the common path prefix, child_count 0, immediately truncated. The repo structure is invisible.
Environment
- memtrace 0.6.0, darwin-arm64
- engine in remote mode on 127.0.0.1:50051
- repo
repo-b, indexed
Repro
get_directory_tree(repo_id=repo-b, max_depth=3, mode=compact)
-> {"node_count": 2,
"root": {"path": ".", "child_count": 1, "children": [
{"path": "home/user/projects", "child_count": 0, "symbol_count": 0, "kind": "dir"}]},
"_truncated_paths": ["home/user/projects"]}
Expected
A bounded tree of the repo's own directories and files, rooted at the repo, the way the docs describe it (built from File-kind graph nodes with .gitignore / .memtraceignore exclusions inherited).
Actual
The absolute-path prefix (/home/user/projects/...) becomes a single directory node with no children, then lands in _truncated_paths. No subtree is rendered. The repro is deterministic: it reproduces on every run against this repo.
Root-cause hint
The tool builds from File-kind nodes (per its own docs), and those nodes carry absolute paths on this install. The tree assembler may be splitting raw path segments without first stripping the repo root, so the whole repo folds under the leading home/user/projects segment. If that read is right, stripping the indexed repo root before segmenting should fix it.
Impact
get_directory_tree is the one-call "map this repo" primitive. On this repo it returns no usable repo structure, so the agent falls back to the file listing the tool was meant to replace.
Happy to send a PR if the repo-root strip turns out to be the right fix.
TL;DR:
get_directory_treereturns a degenerate tree on repos whose File-kind nodes store absolute paths. Instead of the repo layout, you get one leaf node at the common path prefix, child_count 0, immediately truncated. The repo structure is invisible.Environment
repo-b, indexedRepro
Expected
A bounded tree of the repo's own directories and files, rooted at the repo, the way the docs describe it (built from File-kind graph nodes with
.gitignore/.memtraceignoreexclusions inherited).Actual
The absolute-path prefix (
/home/user/projects/...) becomes a single directory node with no children, then lands in_truncated_paths. No subtree is rendered. The repro is deterministic: it reproduces on every run against this repo.Root-cause hint
The tool builds from File-kind nodes (per its own docs), and those nodes carry absolute paths on this install. The tree assembler may be splitting raw path segments without first stripping the repo root, so the whole repo folds under the leading
home/user/projectssegment. If that read is right, stripping the indexed repo root before segmenting should fix it.Impact
get_directory_treeis the one-call "map this repo" primitive. On this repo it returns no usable repo structure, so the agent falls back to the file listing the tool was meant to replace.Happy to send a PR if the repo-root strip turns out to be the right fix.