Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Watcher loses its successful baseline across unwatch/watch

Abierto
  • ¿Algo no está bien?
#2,743 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
47/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
git, sqlite
Área
backend, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
C
Estrellas
45.8k
Forks
3.8k
Merge medio
3 d 14 h
PR fusionados (30 d)
210

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DeusData/codebase-memory-mcp

Todos los issues de DeusData/codebase-memory-mcp

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.