Search/index do not recover when target_sqlite.db is missing but state DB remains

Summary

ccc search / ccc index can fail or silently stay unusable when a project's target_sqlite.db is missing or half-created while the CocoIndex state DB (cocoindex.db) still exists.

In this state, the daemon may consider the project/indexing state already initialized, but the query target database is absent or does not contain code_chunks_vec. A normal daemon restart does not fix it, and ccc index may report files as unchanged without recreating the target vector table.

Environment

• Package: cocoindex-code
• Version: 0.2.37
• Install/runtime: uv tool isolated environment
• Platform: macOS arm64
• Embedding provider: sentence-transformers
• Model: Snowflake/snowflake-arctic-embed-xs

Reproduction

From an initialized project:

ccc index
rm -f .cocoindex_code/target_sqlite.db \
      .cocoindex_code/target_sqlite.db-wal \
      .cocoindex_code/target_sqlite.db-shm
ccc search --limit 1 invoice retry cancellation

Another variant is to leave a half-created target_sqlite.db file without the code_chunks_vec table while keeping .cocoindex_code/cocoindex.db.

Actual Behavior

Observed failures include:

RuntimeError: Index database not found at .../.cocoindex_code/target_sqlite.db.
Please run a query with refresh_index=True first.

and after trying to index again:

Indexing: 1 files listed | 0 added, 0 deleted, 0 reprocessed, 1 unchanged, error: 0
Index not created yet.
RuntimeError: Daemon error: no such table: code_chunks_vec

In a large real project this left ccc search unable to return effective results until the project DBs were manually reset and re-indexed.

Expected Behavior

If target_sqlite.db is missing or does not contain the expected vector table, ccc index, ccc search, and ccc status should detect the broken target index and self-heal by rebuilding the target index instead of relying on stale CocoIndex state.

At minimum, ccc index should not report unchanged while leaving no usable target_sqlite.db.

Notes From Local Debugging

The failure appears to be caused by a mismatch between:

• .cocoindex_code/cocoindex.db, which still records previous incremental state; and
• .cocoindex_code/target_sqlite.db, which is missing or has no code_chunks_vec table.

A local hotfix that resolved the issue:

1. Check that the target DB exists and SELECT 1 FROM code_chunks_vec LIMIT 1 succeeds, rather than only checking whether the file exists.
2. Before handling IndexRequest, SearchRequest, or ProjectStatusRequest, if the target index is invalid:
   • remove the loaded project from the daemon registry so file handles are released;
   • delete both cocoindex.db and target_sqlite.db paths, including -wal / -shm;
   • recreate the project and run indexing again.

One implementation detail: cocoindex.db may be a directory, not a plain SQLite file, so cleanup should handle both files and directories.

Workaround

Manual workaround:

ccc reset -f
ccc index

But this requires the user to know the daemon/index state is inconsistent. It would be better for ccc to recover automatically when the target vector DB is missing or invalid.