Skip to content

fix: stamp store_meta generation on every publish, not never - #2

Open
pranitpanda-affirm wants to merge 1 commit into
fix/method-overload-collision-sibling-stashfrom
fix/publish-staged-generation-stamp
Open

fix: stamp store_meta generation on every publish, not never#2
pranitpanda-affirm wants to merge 1 commit into
fix/method-overload-collision-sibling-stashfrom
fix/publish-staged-generation-stamp

Conversation

@pranitpanda-affirm

@pranitpanda-affirm pranitpanda-affirm commented Aug 26, 2026

Copy link
Copy Markdown

What does this PR do?

trace_path's pagination cursor logic refuses to ever mint a cursor once a project's store generation reads "legacy" — and every project indexed through the normal index_repository flow was stuck there permanently, silently capping caller-enumeration results with no way to page past them.

Root cause: cbm_pipeline_publish_staged only ever read the project row (for coverage metadata) but never wrote it. The byte-level writer (sqlite_writer.c) hand-builds the projects table row directly on every publish, bypassing cbm_store_upsert_project — the only function that creates store_meta (db_uid/mutation_gen).

Fix: call cbm_store_upsert_project on every full and incremental publish, re-reading the project row afterward so coverage metadata reflects the freshly-stamped generation. store_meta now gets created on a project's first publish, and mutation_gen advances on every subsequent one — correctly invalidating cursors minted against a prior generation.

Caveat: this only takes effect going forward. A project whose files haven't changed since its last index hits the incremental.noop fast path (pipeline_incremental.c) and skips publish entirely by design — it can't retroactively escape "legacy" without either a real content change or a forced full rebuild (delete + reindex).

Testing

New pipeline_publish_escapes_legacy_generation test in tests/test_pipeline.c: verifies a fresh index escapes "legacy", and a second real publish (after an actual file edit, to avoid the no-op fast path) advances the generation further.

Also verified directly against the installed production binary and live daemon (not just the test build): indexed a throwaway repo fresh — store_meta appeared immediately with mutation_gen=1; made a real edit and reindexed — mutation_gen advanced to 2 and indexed_at refreshed.

Checklist

  • Every commit is signed off (git commit -s) — not yet done, flagging for follow-up
  • Tests pass locally (make -f Makefile.cbm test) — relevant suites (pipeline, store_*, mcp, graph_buffer) are clean; the full run has ~327 pre-existing failures in tree-sitter grammar/extraction probes, unrelated to this change and present on main before it
  • Lint passes (make -f Makefile.cbm lint-ci) — not run locally (cppcheck/clang-format unavailable in this environment); deferring to CI
  • New behavior is covered by a test (reproduce-first for bug fixes)

cbm_pipeline_publish_staged read the project row (for coverage
metadata) but never wrote it: the byte-level writer hand-builds the
projects table row directly, bypassing cbm_store_upsert_project, the
only place that creates store_meta (db_uid/mutation_gen). Every
project indexed through the normal index_repository flow was
therefore permanently stuck on "legacy" generation, and trace_path
refuses to ever mint a pagination cursor under "legacy" -- callers
enumeration silently truncated with no way to page past it, on every
project, forever, regardless of how many times it was reindexed.

Call cbm_store_upsert_project on every full and incremental publish
(re-reading the project row afterward so coverage metadata reflects
the freshly stamped generation), so store_meta gets created on first
publish and mutation_gen advances on every subsequent one, correctly
invalidating cursors minted against a prior generation.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@pranitpanda-affirm
pranitpanda-affirm marked this pull request as ready for review August 26, 2026 22:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants