Worker continuously hangs and indexing process gives up eventually

Version

codebase-memory-mcp 0.9.0

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

codebase-memory-mcp cli index_repository --repo-path "D:\path\to\your\repo" --mode fast
level=info msg=mem.init budget_mb=32610 total_ram_mb=65220
level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=C:/Users/lwu/.cache/codebase-memory-mcp/logs/.worker-25072.log
level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=C:/Users/lwu/.cache/codebase-memory-mcp/logs/.worker-25072.log
level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=C:/Users/lwu/.cache/codebase-memory-mcp/logs/.worker-25072.log
level=warn msg=index.file_quarantined path=vi.mdf.nodsl.modeling.if/src/aquintos/mdf/dblayer/NullDynamicLoadService.java outcome=hang attempt=2
level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=C:/Users/lwu/.cache/codebase-memory-mcp/logs/.worker-25072.log
level=warn msg=index.file_quarantined path=aquintos.metric.engine/src/aquintos/metric/engine/creation/MetricModelCreationConstants.java outcome=hang attempt=3
level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=C:/Users/lwu/.cache/codebase-memory-mcp/logs/.worker-25072.log
level=warn msg=index.file_quarantined path=aquintos.analyse.problemview/src/aquintos/analyse/problemview/views/AnalyseProblemView.java outcome=hang attempt=4
level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=C:/Users/lwu/.cache/codebase-memory-mcp/logs/.worker-25072.log
level=warn msg=index.file_quarantined path=aquintos.metric.engine/src/aquintos/metric/engine/util/Messages_de.properties outcome=hang attempt=5
level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=C:/Users/lwu/.cache/codebase-memory-mcp/logs/.worker-25072.log
level=warn msg=index.supervisor.unattributable action=give_up
level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=C:/Users/lwu/.cache/codebase-memory-mcp/logs/.worker-25072.log
{"status":"error","outcome":"hang","hint":"Indexing worker timed out (a file made no progress). The worker was terminated and the server survived. Re-run to retry.","repo_path":"D:\path\to\your\repo"}

This was run on a 350.57MB folder. It seems only not to be working in this specific subfolder. The files it hangs on are seemingly unrelated and quarantined files change between runs. It also does not seem to be related on size as a neighbouring folder (270MB) indexed successfully within a minute. Worker logs are completely empty.

Reproduction

codebase-memory-mcp cli index_repository --repo-path "D:\path\to\your\repo" --mode fast

I can't share the repository because it is proprietary. I unfortunately was not able to create a dummy project that triggers the same bug. I tried the indexing process on the two biggest subfolders (that contained files being quarantined) within the failing folder and both finished successfully.

The indexing process was run on a folder within a Java/Eclipse RCP project with 350.57MB in size on Windows 11.

Logs

Worker logs were completely empty

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

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.

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.

Thanks for the detailed containment log. The changing quarantine candidates and successful indexing of the individual subfolders suggest a repository-level progress or supervision problem rather than one deterministic Java file.

Please attach the output of index_status after the failed run, the total discovered file count, whether this root is a Git working tree, and a directory-level file-count breakdown for the top-level modules. If possible, retry only with a diagnostic v0.9.1 build once one is available; the current zero-byte worker log is itself part of the stability gap tracked in #1132. Marking awaiting-reporter for those non-proprietary diagnostics while keeping this in 0.9.1-rc.

This is a Git working tree. The folder contains 476 top-level folders. Ive includeed the counts here for the most-filed 35 folders:

6352
3521
2878
2588
2298
1864
1847
1387
1359
1326
1300
1249
1171
1060
991
984
915
825
806
804
793
777
767
764
761
743
718
692
690
683
626
540
517
503
472

As the indexing of the folder failed, it is not listed within the indexed projects and I can't run index_status on it.

This (also included in my previous comment):

{"status":"error","outcome":"hang","hint":"Indexing worker timed out (a file made no progress). The worker was terminated and the server survived. Re-run to retry.","repo_path":"D:\path\to\your\repo"}

was printed at the end of the indexing attempt.

Thanks for the follow-up. The Git working-tree confirmation, top-level file-count distribution, and terminal timeout result supply the requested non-proprietary diagnostics. I removed awaiting-reporter. Because the failed root is never registered, index_status cannot be collected; that absence is itself part of the reproduction. This is back in the high-priority 0.9.1-rc maintainer queue.

I can reproduce this exact symptom (worker hangs → retries → index.supervisor.unattributable action=give_up → final {"status":"error","outcome":"hang", ...}) on a fully public repo, which might help since the OP couldn't share their proprietary one.

Repro (public, shareable)

Repo: llvm-project, commit 9a2d9c7fef47c0af321150f75d8f21db06cccb43
Target: the llvm/ subdirectory specifically (~80.8k files on disk, ~8.5k after filtering)
Command: codebase-memory-mcp cli index_repository --repo-path <path>\llvm-project\llvm --mode fast
Env: CBM_WORKERS=1 (set to control the memory issue from Memory not released after indexing: 20GB+ RSS for 5MB of indexed data #832/fix: memory not released after indexing (20GB+ RSS for 5MB data) #831 — without it, memory runs away before you even get to see this hang, see my comment there)
Platform: Windows 11, 32GB RAM

Observed

Exactly 3 attempts, each hangs after 6–15 minutes at a different point in the RSS growth curve (~4.4GB / ~4.7GB / ~6.3GB peak before being killed), then supervisor gives up:

level=info msg=index.supervisor.reap outcome=hang exit_code=1 signal=0
level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1 log=.../.worker-36752.log
(repeated 3x)
level=warn msg=index.supervisor.unattributable action=give_up
{"status":"error","outcome":"hang","hint":"Indexing worker timed out (a file made no progress)...","repo_path":"...\\llvm-project\\llvm"}

Like the OP, my worker log file (.worker-*.log) was completely empty (0 bytes) every time — no indication of which file it was stuck on. No index.file_quarantined messages ever appeared for me either (unlike the OP's later attempts), so whatever heuristic decides which file to quarantine doesn't seem to be triggering consistently, which lines up with the OP's note that "quarantined files change between runs."

Smaller subdirectories of the same monorepo (e.g. mlir/ at 2,867 files, polly/ at 930 files) index successfully, sometimes after 1 internal hang+retry cycle that does self-recover — so this seems specific to something about scale and/or specific file(s) only present once you get deep enough into llvm/'s ~8.5k files, not a property of any single small file in isolation. That's consistent with the OP's finding that neighboring subfolders indexed fine.

Since llvm/ is a permanent, public, stable target (not a moving proprietary codebase), I'm happy to help narrow down which file(s) trigger it if a maintainer can point me at what diagnostic flags/env vars would get past the empty-log problem (e.g. a per-file verbose/trace mode, or a way to disable the timeout so the worker just runs to completion however long it takes).

Thanks, this public LLVM commit and exact llvm/ subdirectory make the hang reproducible without proprietary code. The current CBM_DIAGNOSTICS=1 path records process trajectory, but there is no existing flag that reliably recovers the last file after this zero-byte worker-log failure. That missing attribution is part of the bug, so please do not spend more time trying undocumented flags. The scale boundary and the CBM_WORKERS=1 setup are now sufficient maintainer evidence.

Additional v0.10.3 reproduction

Environment

Windows 11 Pro 10.0.26200 (x64)
Installed standard executable
Public Git working tree: Today20092/podcast-automixer

Observed failure

The daemon repeatedly records the same supervisor failure:

level=warn msg=index.supervisor.worker_failed outcome=hang exit_code=1
level=warn msg=daemon.index.recovery_unattributable action=stop
level=warn msg=mcp.request protocol=jsonrpc method=tools/call tool=index_repository status=error duration_ms=1808233

Multiple attempts lasted approximately 1,808,233–1,808,426 ms (about 30.1 minutes).
Recent referenced worker logs are 574 bytes.
The worker logs contain only allocator/budget initialization and the raw-JSON deprecation warning.
They do not identify a file or pipeline phase.

Diagnostics

CBM_DIAGNOSTICS=1 was enabled before daemon startup.

The latest short trajectory contained 21 samples over 100 seconds:

Daemon RSS: 13,774,848 → 15,814,656 bytes
Committed memory: 38,850,560 → 50,991,104 bytes

This short capture covers a list_projects reproduction, not a complete 30-minute indexing attempt.

Written by AI: GPT-5.6 Sol (light mode).

@Skace-VI

@Skace-VI — you gave us the Git working-tree confirmation and the full top-level file-count distribution for a repository you cannot share, which is about as much as anyone could reasonably provide; the label came off then and nothing is waiting on you.

@Khusan-Khujakeldiev's public llvm/ reproduction at a pinned commit, and @Today20092's fresh v0.10.3 run with the ~30-minute duration_ms=1808233 and a 574-byte worker log naming neither a file nor a phase, mean this is reproducible without proprietary code and is still present on the current release. Honest status: not root-caused. The missing attribution is itself part of the bug — there is no flag today that recovers the last file after this failure, so please do not spend more time hunting undocumented ones.

Tonight's v0.10.5 is being cut for the issues that make cbm impossible to operate, and indexing that retries, gives up, and explains nothing belongs in that set. Sorry for how much time this has cost you all.

fix(index): make a crashed worker's log survive and name the run

@Skace-VI

Thank you, @Skace-VI, @Khusan-Khujakeldiev and @Today20092! Between you, this became reproducible on public code.

One part is fixed. Since v0.10.5, the worker log is written durably, with a header and the files that were in flight, so a hang now names where it happened instead of leaving a 0-byte log. The hang itself isn't root-caused yet. If you hit it on v0.11.0, the .worker-<pid>.log from that run is exactly the evidence we're missing. Please attach it, redacting paths as needed.

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.

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.

Thank you for the public reproductions and the non-proprietary diagnostics. The last update improved attribution but did not establish the hang’s cause. If a normal run still hits it on v0.11.0 or newer, its worker log is useful; the pinned public reproduction is already available for maintainer investigation.

Navigation Menu

Repository navigation

Worker continuously hangs and indexing process gives up eventually #1130

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Repro (public, shareable)

Observed

Additional v0.10.3 reproduction

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Worker continuously hangs and indexing process gives up eventually #1130

Description

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Activity

github-actions commented on Jul 16, 2026

DeusData commented on Jul 16, 2026

Skace-VI commented on Jul 21, 2026

DeusData commented on Jul 22, 2026

Khusan-Khujakeldiev commented on Jul 23, 2026

Repro (public, shareable)

Observed

DeusData commented on Jul 24, 2026

Today20092 commented on Aug 14, 2026

Additional v0.10.3 reproduction

DeusData commented on Aug 14, 2026

DeusData commented on Sep 26, 2026

github-actions commented on Sep 26, 2026

github-actions commented on Oct 19, 2026

DeusData commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions