Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

macOS: two per-conversation servers run duplicate full index_repository workers on the same repo simultaneously (~400% CPU each, respawning every few minutes) — per-repo worker serialization still missing (0.9.0)

Aperta
  • Qualcosa non va?
#2,673 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c, macos, sqlite
Ambito
backend, databases, performance

Direzione di ricerca

Start by reading #1083 for the existing per-repository coordination proposal, then trace the index_repository worker entry point and the code that quarantines corrupt databases (the issue names no source files or tests). Reproduce with two server instances indexing the same active repository and inspect the logs and database behavior. Done means workers for one repository are coordinated across instances and repeated full indexing or database corruption no longer occurs under this scenario.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

awaiting-reporter bug editor/integration parsing/quality stability/performance
Environment
  • codebase-memory-mcp 0.9.0 (latest is v0.12.1 — happy to retest on it, but filing this as a macOS datapoint since the fix suggested in #1083 does not appear to have landed)
  • macOS 26 arm64 (Apple Silicon, 96 GB RAM)
  • Install channel: install.sh → ~/.local/bin/codebase-memory-mcp
  • Multiple concurrent MCP client sessions against the same repo (one long-lived CLI host), each conversation spawning its own codebase-memory-mcp server instance
  • Repo: ~2.2 GB worktree, ~18.5k source files, actively modified during the workday (build outputs + tool-generated temp files). build/ dirs are not git-ignored (partly on us).
What happened

The machine sat at load average ~55 with 0% idle CPU while essentially idle from the user's perspective. Two distinct server instances (two different MCP conversations) each spawned a full index_repository worker for the same repo at the same time:

PID 13629  456.9% CPU  cli --index-worker index_repository {"repo_path":"/Users/<user>/Projects/<repo>"}   (parent server 46586)
PID 14093  401.4% CPU  cli --index-worker index_repository {"repo_path":"/Users/<user>/Projects/<repo>"}   (parent server 66866)

And this is not a one-off: paired skip-report logs in ~/.cache/codebase-memory-mcp/logs/ show one full extraction run per server, roughly every 1–8 minutes while the worktree is being modified:

12:41, 12:42   (×2 files)
12:43, 12:44   (×2)
12:46          (×2)
12:49          (×2)
12:53          (×2)
12:59          (×2)
13:01          (×2)

Each run re-scans/re-parses the whole tree (each skip report lists the same parse timeouts, e.g. UFIPanel/iosport/**/build/**/Intermediates.noindex/*-primary.d — the .d-parsed-as-D issue from #2414) and burns 400%+ CPU for minutes. Net effect: CPU never gets a break.

Aggravator observed the same day: the project DB was quarantined as ~/.cache/codebase-memory-mcp/<repo>.db.corrupt (669 MB, 12:51 local), throwing away the whole graph and forcing a from-scratch rebuild. The cache dir currently holds 9 .db.corrupt files across projects (Jul → Oct). Suspect: concurrent multi-process SQLite writers with no per-repo coordination — same root as the WAL starvation in #1083.

Diagnosis

Same root pattern as #1083, macOS variant, CPU-flavored instead of WAL-flavored:

  1. No per-repo serialization of index workers across server instances — N conversations = N duplicate full indexes running concurrently.
  2. Staleness triggers a full re-extract, not an incremental update, and there is no debounce/backoff while the tree is churning (#1884) — on an active worktree the index is stale again before a rebuild finishes, so workers respawn forever.
  3. Corruption → silent discard → full rebuild (#391 family), which resets all progress and feeds loop #2.
Suggestions
  1. Implement #1083's suggestion 2 cross-platform: a per-repo file lock so a second index_repository queues or no-ops instead of running duplicate full indexes. Locking is not a Windows-only concern.
  2. Debounce/backoff re-index triggers on hot worktrees; consider incremental (mtime/hash) extraction instead of full re-parses (#1884).
  3. Harden DB writes against the recurring .db.corrupt quarantines; log a loud warning when it happens (users only find out via CPU).
Related issues
  • #1083 (per-conversation servers + 11 concurrent index workers, WAL starvation, Windows)
  • #2400 (multiple server processes), #45 / #1084 / #2093 (high CPU family)
  • #1884 (debounce artifact re-export), #391 (silent index corruption)
  • #2414 (.d dep-info files parsed with the D grammar — the exact parse timeouts in our skip reports)
  • #2649 (index_repository OOM)
Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 6h
PR unite (30g)
201

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DeusData/codebase-memory-mcp

Tutte le issue di DeusData/codebase-memory-mcp

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.