fix(update): honor yaml source_root so update stops mass-deleting the index

[HumanBean17]

Summary

java-codebase-rag update resolved source_root differently from every other operator command and, for the documented nested-config layout, pointed cocoindex at the config subdir (no Java) while pointed at the real, fully-populated index — so cocoindex treated every indexed file as removed and mass-deleted them.

Root cause

run_update passed the discovered config dir as an explicit source_root to resolve_operator_config (installer.py):

cfg = resolve_operator_config(source_root=project_root, cli_index_dir=None)

A non-None source_root routes into the explicit-override branch that skips the YAML source_root field (config.py). With a config in my-project-context/ next to source_root: ../, update then resolved source_root to my-project-context/ (only the YAML) but index_dir to the real index one level up (../.java-codebase-rag). cocoindex, told the source had no Java but aimed at a full index, began deleting every vector.

This is the identical bug class #316 fixed for the MCP server — its own docstring warns that a non-None source_root skips the YAML field. run_update (added in #290, before #316 existed) was the last production caller still passing a discovered dir.

Symptoms this explains

• increment = clean 6 s no-op, but update's identical index phase hung 5 min+ at "Updating index (Lance + graph)…".
• Lance _deletions grew monotonically (the mass row-deletions).
• After ctrl+C left cocoindex.db mid-reconcile, the next increment (which resolves the root correctly) re-embedded nearly everything → 1000 s+.

The fix

One line — pass source_root=None so the YAML source_root is honored exactly like increment/init/reprocess:

cfg = resolve_operator_config(source_root=None, cli_index_dir=None)

The discover_project_root(cwd) no-config guard above it is unchanged. run_install is unaffected (it passes the user-confirmed Java root). run_update is now the only production caller of resolve_operator_config besides the (already-fixed) MCP server and the CLI, and all honor the YAML field consistently.

Validation (TDD)

• New regression test test_update_honors_yaml_source_root_for_nested_config_dir mirrors the reported layout, captures the env handed to cocoindex, asserts JAVA_CODEBASE_RAG_SOURCE_ROOT = the YAML root (not the config dir) and JAVA_CODEBASE_RAG_INDEX_DIR = the real index. Watched it fail RED (SOURCE_ROOT off by one level), then pass GREEN.
• .venv/bin/ruff check . — clean.
• .venv/bin/python -m pytest tests -q → 775 passed, 11 skipped (heavy-gated). No regressions.

User-visible behaviour changes

• java-codebase-rag update now resolves source_root consistently with increment/init/reprocess/the MCP server. For the common case (config at the source root, or running from the source root) behaviour is unchanged. For a config living in a subdirectory of the Java tree (the my-context/ + source_root: ../ layout documented in fix(config): consistent index_dir/source_root resolution for CLI and MCP #316), update's index phase now operates on the correct source instead of mass-deleting the index.

• No reindex required. No schema, ontology, embedding, or env-var change. Existing indexes remain valid.

Recovery for affected indexes

If an index was damaged by the bug (run update from a nested config dir before this fix), from the config dir:

pkill -f "cocoindex update"; pkill -f "build_ast_graph"   # stop any stuck run
java-codebase-rag erase --yes                              # wipe corrupted index (config .yml preserved)
java-codebase-rag init                                     # re-create from correct source_root

increment/init/reprocess resolve the root correctly, so they are safe to run even before applying this fix; only update's index phase was affected.

🤖 Generated with Claude Code