fix(pipeline): preserve ADRs during incremental reindex#992
Conversation
d0d5b24 to
3852990
Compare
|
Thanks for the ADR persistence fix. I have triaged this into 0.9.1-rc as a normal-priority UX/behavior bug fix. Review focus will be ADR state across incremental DB replacement and making sure we do not restore stale summary data by accident. |
|
Thanks. |
|
Reviewed and verified — this is correct and ready; it just needs a rebase onto current main (which moved since you opened it). I did the rebase locally to confirm the resolution and that the fix still works, so here's exactly what's needed: Verified: both The only conflict is in /* #992: restore the captured ADR before persisting hashes, mirroring the
* full-reindex path (#516) — the DB replacement above dropped it. */
if (saved_adr && cbm_store_adr_store(hash_store, project, saved_adr) != CBM_STORE_OK) {
cbm_log_error("incremental.err", "msg", "adr_restore", "project", project);
}
bool hash_records_complete = persist_hashes(hash_store, project, files, file_count,
mode_skipped, mode_skipped_count);(Your Rebase onto current main with that resolution and push; once it's green I'll merge immediately. Thanks — preventing ADR loss on the incremental path is a genuine data-safety fix, and mirroring #516's invariant is exactly right. |
Signed-off-by: Mustapha <m88e54ik@gmail.com>
3852990 to
207e9a5
Compare
|
Rebased onto current Resolved the Local verification:
I could not run Thank you. |
What does this PR do?
Preserves
manage_adrcontent whenindex_repositorytakes the incremental reindex path.This is a follow-up to #516. The full reindex path already captures ADR content from
project_summaries.summarybefore replacing the SQLite DB and restores it afterward. The incremental path also replaces the DB indump_and_persist(), but it only repersisted graph data, file hashes, coverage rows, and FTS state. Any ADR stored throughmanage_adrwas therefore silently dropped on the next incremental rebuild.The failure shape is:
manage_adrmodeupdate.get; content is present.index_repositoryroutes through incremental reindex.project_summarieswas recreated without the previoussummary.This PR mirrors the full-reindex preservation behavior in
src/pipeline/pipeline_incremental.c:cbm_gbuf_dump_to_sqlite()recreates the DB and it is reopened, write that ADR content back withcbm_store_adr_store();It also adds
pipeline_adr_survives_incremental_reindex, which indexes a tiny repo, stores an ADR, changes one existing file to force the incremental route, and asserts that the ADR content is still present afterward.This PR is intentionally scoped to ADR loss during incremental reindex. It does not attempt to address any separate stale-WAL/listed-but-unqueryable project lookup behavior.
Verification
git fetch origin mainand rebase onto currentorigin/main(6b57db2) succeeded without conflicts.make -j2 -f Makefile.cbm cbmsucceeded.manage_adr updatestored content;manage_adr getreturned the content;index_repositoryafter changing one file reported"adr_present":true;manage_adr getreturned the original content.make -j2 -f Makefile.cbm build/c/test-runnersucceeded.ASAN_OPTIONS=detect_leaks=0 build/c/test-runner pipelinereached and passed the newpipeline_adr_survives_incremental_reindextest, including thepipeline.route path=incrementalbranch.pipelinesuite still exits non-zero with an unrelated existing failure:pipeline_backpressure_futile_nap_disengagesattests/test_pipeline.c:6801(220 passed, 1 failed).Checklist
git commit -s) — required, CI rejectsunsigned commits (DCO, see CONTRIBUTING.md)
make -f Makefile.cbm test)make -f Makefile.cbm lint-ci)