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

Watcher loses its successful baseline across unwatch/watch

Aperta
  • Qualcosa non va?
#2,743 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
47/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
git, sqlite
Ambito
backend, devtools

Direzione di ricerca

Start by tracing how daemon sessions remove and recreate project watches, then inspect the watcher’s Git HEAD and dirty-signature baseline alongside graph database generation checks. Reproduce the unwatch/commit/rewatch sequence from the issue and check how successful, failed, and busy-skipped indexing affect saved state. Done means rewatching detects changes made while unwatched, while unchanged dirty work does not trigger a redundant full reindex.

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

Descrizione

bug ux/behavior
Version

codebase-memory-mcp -v0.12.1

Platform

Linux (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Description

In v0.12.1, a project watch can be removed when its final daemon session
subscriber disconnects while the daemon itself remains alive. Re-registering
the same project creates a fresh watcher state. Its initial poll adopts the
current Git HEAD as the baseline and starts with an empty dirty-state
signature, without checking whether that graph generation was successfully
indexed before the disconnect.

This can cause two observable failures:

  • If the previously indexed worktree was dirty and remains unchanged, the
    reconnect can trigger a redundant full reindex.
  • If a commit is made while the project is unwatched and the worktree is clean
    when it reconnects, the fresh baseline can absorb the new HEAD; the
    watcher then sees no change and may leave the graph stale.

The issue is limited to a daemon that stays running while the final watch is
removed and later recreated. A daemon restart already loses all in-memory
watcher state.

Reproduction

Reproduction

  1. Start the daemon and watch a Git project.
  2. Make a worktree change and let the watcher index it successfully.
  3. Disconnect the final session that owns this project's watch, without
    restarting the daemon.
  4. While the project is unwatched, commit a change and leave the worktree
    clean.
  5. Reconnect the session so the project is watched again.

The watcher initializes from the new HEAD and does not schedule an index for
the commit made while disconnected. An unchanged dirty worktree can also
reproduce the redundant-index case by reconnecting without step 4.

Expected behavior

The daemon should retain the last successfully indexed Git HEAD and dirty
signature across a watch removal/re-registration for the same project and
root. It should detect changes that happened while the project was unwatched.
The saved baseline should only be reused while the project's graph database
generation is unchanged; a replaced or missing database should force an
index. Failed and busy-skipped index attempts must not advance the saved
baseline.

Logs
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.
Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 16h
PR unite (30g)
203

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.