index_repository: deterministic contained worker crash (0-byte log) when cache dir + derived project name exceed Windows MAX_PATH #1450

Version

codebase-memory-mcp 0.9.0

Platform

Windows 11 amd64

Install channel

GitHub release archive

Binary variant

ui

What happened, and what did you expect?

index_repository dies with a contained worker crash, deterministically, when the cache directory path plus the derived project name exceed the Windows MAX_PATH limit of 260 characters.

{"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file."}

Two things make this expensive to diagnose:

1. The hint points at the wrong thing. "Crashed on a file … re-run to retry" sends you looking for a culprit source file and encourages retrying. Neither helps: the input is 16 lines of Python across 3 files, and retrying fails 100% of the time.
2. The worker log is 0 bytes. logs/.worker-*.log lives under the same over-long cache directory, so the worker cannot open it either — the one diagnostic that would explain the failure is silenced by the failure itself.

Expected: either long paths handled transparently, or an explicit error naming the path and its length.

Reproduction

Any dummy project works — the content is irrelevant, only the path lengths matter. Three files, 16 LOC:

svc/api/routes.py      # FastAPI APIRouter(prefix="/api/items") + one @router.get("")
svc/client/fetch.py    # httpx.get("/api/items")

Index it with the cache directory set alongside it, both under a deep path:

export CBM_CACHE_DIR="<deep>/_cache"
cli index_repository --repo-path "<deep>\svc" --mode moderate

The derived project name is the repo path with separators replaced, so a deep repo produces a long .db filename inside an already-long cache dir:

cache dir : 151 chars
db name   : 149 chars   (C-Users-...-scratchpad-repro-svc-a.db)
full path : 301 chars   >  MAX_PATH (260)

Isolation matrix — same binary, same 16-LOC project, --mode moderate:

Neither path is a problem on its own; it is the sum, which is what MAX_PATH constrains. Moving the same project to C:\tmp\r1133 with a short cache dir indexes 12/12 without a single failure.

Logs

logs/.worker-<pid>.log is created and stays at 0 bytes for every failed run. Nothing is flushed, so there is no stack, no path, and no errno.

Project scale

25 nodes / 41 edges. Scale is irrelevant here — this is a path-length failure, not a resource one.

Suggested fix

In rough order of preference:

1. Use the extended-length path prefix (\\?\) for the store's own files on Windows, which lifts the 260-character limit for the .db, -wal, -shm and worker logs.
2. Bound the derived project name — hash or truncate it past some length instead of embedding the full path verbatim in the filename.
3. Failing both, fail explicitly. An error that names the path and its length would have turned this from an afternoon into a minute. This is the same fail-loudly principle already accepted for Inline property map in MATCH pattern silently matches nothing — should error if unsupported #1111 and cross-repo-intelligence: --target-projects flag silently parses to zero targets; with raw-JSON args the worker crashes (0-byte log) #1133.

Worth noting that (3) alone would help more than it sounds: the current combination of a misleading hint and a 0-byte log actively points away from the cause.

Related

Possibly a contributing factor in some reports of contained worker crashes with empty logs (#1132, #1379), though I would not assume it accounts for all of them — I have separately observed nondeterministic contained crashes with short paths, which this does not explain.

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.