Summary of Changes

Hello @tae898, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new public API to the LSMVectorIndex that enables an immediate and forced rebuild of its underlying vector graph. This functionality is particularly useful after bulk data operations, allowing users to ensure the graph is up-to-date without waiting for a lazy build trigger. The implementation includes safeguards against concurrent rebuilds and ensures the graph is reconstructed from a consistent state.

Highlights

• New API for eager graph rebuild: Introduced buildVectorGraphNow API in LSMVectorIndex to allow immediate, on-demand rebuilding of the vector graph, bypassing lazy build mechanisms.
• Concurrency control for rebuilds: Implemented a guard using an index availability check to prevent concurrent graph rebuilds, ensuring callers can retry cleanly if the index is busy.
• Forced rebuild from on-disk state: The eager rebuild process now explicitly resets the mutation counter and rebuilds the graph from on-disk pages, effectively ignoring lazy build thresholds.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

🧪 CI Insights

Here's what we observed from your CI run for 0de08dc.

🟢 All jobs passed!

But CI Insights is watching 👀

How about the existent.build() API?

@lvca

Right now LSMVectorIndex.build() doesn’t actually rebuild the vector graph. It only rewrites the pages unless the index is in the special LOADING state. In normal life the state is IMMUTABLE, so build() exits and the first queries still trigger a lazy graph build. To make it a real rebuild, the code has to flip the state back to LOADING (or otherwise force the graph rebuild) before/inside build(). And the SQL REBUILD INDEX path drops/recreates without restoring vector metadata (dimension, similarity, etc.), which is why rebuilt vector indexes come back broken (dimension 0).

I see in the code this:

  public long build(final BuildIndexCallback callback, final GraphBuildCallback graphCallback) {
      if (status.compareAndSet(INDEX_STATUS.AVAILABLE, INDEX_STATUS.UNAVAILABLE)) {
        try {
          final DatabaseInternal db = getDatabase();

          // PHASE 1: Mark index as BUILDING and disable WAL
          persistBuildState(BUILD_STATE.BUILDING);
...

So it forces the state to BUILDING every time.

Ok, I got it now. Merging it