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

Wiping .index/lancedb leaves an empty index that every health surface reports as healthy

Aperta
  • Qualcosa non va?
#501 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python, sqlite
Ambito
databases, observability

Direzione di ricerca

Start with reconcile_index_once() and the .index_reconcile_version marker, which the issue says sits in .index/ rather than .index/lancedb/, then trace how cascade status and the GET /health probe read the sqlite ledger. Done means that after rm -rf .index/lancedb, the system reports the mismatch (a per-table row count beside the done count) instead of healthy, and a test covers that case. The issue leaves open whether to refuse startup, enqueue a rebuild, or move the marker, so settle that choice with the maintainers before writing code.

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

Descrizione

enhancement

Summary

Deleting ~/.everos/.index/lancedb leaves a store that contains nothing and reports perfect health: cascade status shows every file done with lag: 0, GET /health reports cascade.healthy: true with zero failures, and search returns 0 hits against an empty table. Markdown is untouched, so nothing is lost — but nothing says anything is wrong either.

This is a detectability gap, not an undocumented trap. The hazard itself is documented, clearly and in more than one place (see Already documented below). What is missing is that the running system can tell this state apart from a healthy one with a two-number comparison, and doesn't.

Found while reproducing #334 on current main; the rm -rf came from that report's steps.

Reproduce

EverOS 1.4.1 at a345d08, isolated memory root, real everos server start, DeepInfra Qwen3-Embedding-4B. Corpus built with EverOS's own EpisodeWriter: 106 daily-log files, 1060 entries.

  1. Start the server, let the cascade index everything (cascade status → done: 106, lag: 0).
  2. Stop the server.
  3. rm -rf <root>/.index/lancedb — only lancedb, leaving .index/sqlite and the rest of .index/ in place.
  4. Start the server again.

Observed

surface reports
everos cascade status pending 0 · done 106 · last_processed 106 · lag 0
GET /health status: ok · cascade.healthy: true · failed_permanent 0 · failed_retryable 0
LanceDB rows episode 0 · atomic_fact 0 · user_profile 0
POST /api/v2/memory/search 0 hits (HTTP 200)
Markdown source of truth 106 files, intact

Mechanism

  1. The cascade ledger survives the wipe. It lives in .index/sqlite/system.db, so every md row is still status='done' and the scanner enqueues nothing.
  2. The self-heal marker survives too. reconcile_index_once() force-enqueues every indexed md once per INDEX_RECONCILE_VERSION, recording that in <index_dir>/.index_reconcile_version. That file sits in .index/, not inside .index/lancedb/, so wiping the backend leaves it holding the current version and the pass is a no-op.
  3. Nothing compares the ledger against the tables. "Every row done" and "the tables are empty" are never checked against each other, at startup or in the health probe.

Already documented — scope this accordingly

An earlier revision of this issue claimed the hazard was "only visible to someone who already thought to read the rebuild command's help". That was wrong, and it overstated the problem. The project documents it properly:

  • docs/cascade_runbook.md has a "Why not a bare rm" comparison table — rm -rf .index/lancedb → "❌ scanner skips done rows → empty index" — and a bolded paragraph repeating it in prose.
  • docs/how-memory-works.md carries the same warning.
  • The everos cascade rebuild docstring states it.
  • The LanceDBSchemaMismatchError message now names everos cascade rebuild. The 1.1.2-era text that pointed users at rm -rf ~/.everos/.index/lancedb (quoted in #334) is gone.

So the product no longer walks anyone into this, and an operator who reads the runbook will not hit it. Severity should be read as hardening, not as an outage: reaching this state takes a deliberate rm -rf against an internal directory that the documentation tells you not to delete.

What is still worth fixing

The detection, not the documentation. The state is trivially distinguishable and the system reports it as healthy:

  • Startup check. When the ledger says a kind is fully done but that kind's table holds zero rows, something external removed the index — log an error and either refuse to start or enqueue a rebuild. A row count per table is O(1) against LanceDB metadata.
  • Move the marker. Put .index_reconcile_version inside .index/lancedb/ so wiping the backend also invalidates the marker that governs re-indexing it. The reconcile pass then self-arms after exactly the operation it should fire for, and this specific state stops existing.
  • Surface the comparison. A rows count per table beside the queue counters in GET /health and cascade status. An operator seeing done: 106 next to episode rows: 0 needs no runbook.

Recovery (verified)

everos cascade rebuild restores it — 1060 rows back from the same 106 Markdown files, measured. No memory content is lost.

Related: #334 (origin of the rm -rf), and the same "the system cannot tell a broken index from an empty corpus" shape as #434 and #364.

Lingua principale
Python
Stelle
13.3k
Fork
926
Merge medio
17h 40m
PR unite (30g)
31

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 EverMind-AI/EverOS

Tutte le issue di EverMind-AI/EverOS

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.