apache/cassandra · warning

Failed to incrementally build indexes

Error message

Failed to incrementally build indexes {}

What it means

When indexes with isBuilt=false or isIndexed=true are built incrementally, SecondaryIndexManager submits an index build to CompactionManager and attaches a FutureCallback. On failure of that background compaction-driven build, the callback logs this WARN and propagates the failure into the `build` promise so the composed future (and callers like buildIndexesBlocking) see the error. The index is subsequently marked failed.

Solutions

  1. Check the propagated Throwable on the returned future / subsequent 'Index build of {} failed' log to find the root cause.
  2. Run nodetool rebuild_index (or REBUILD INDEX) on the affected indexes to retry from scratch.
  3. If caused by concurrent compaction, retry after compaction pressure subsides.
  4. Ensure sufficient disk space and that the node was not shut down mid-build.

Example fix

// before: build failure only warned, caller must notice
logger.warn("Failed to incrementally build indexes {}", getIndexNames(groupedIndexes));
build.tryFailure(t);
// after: react to the composed future to trigger a rebuild
build.addListener(() -> { if (!build.isSuccess()) logger.error("Scheduling rebuild for {}", getIndexNames(groupedIndexes)); });
Defensive patterns

Strategy: try-catch

Try / catch

try { buildResult.get(30, TimeUnit.MINUTES); } catch (ExecutionException e) { logger.error("index build failed, scheduling rebuild_index", e.getCause()); }

Prevention

When it happens

Trigger: submitIndexBuild future completing exceptionally — e.g. the underlying SSTable being compacted away mid-build, an IOException while reading columns during the index build, or a shutdown interrupt cancelling the compaction task.

Common situations: Adding a new secondary index while heavy compaction is running; node decommission/shutdown interrupting an index build; SAI or custom index throwing during scan of memtable/SSTable data.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/ac0d950b5d286ae4. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/index/SecondaryIndexManager.java:623

        Map<Index.IndexBuildingSupport, Set<Index>> byType = new HashMap<>();
        for (Index index : toBuild)
        {
            Set<Index> stored = byType.computeIfAbsent(index.getBuildTaskSupport(), i -> new HashSet<>());
            stored.add(index);
        }

        // Schedule all index building tasks with callbacks to handle success and failure
        List<Future<?>> futures = new ArrayList<>(byType.size());
        byType.forEach((buildingSupport, groupedIndexes) ->
        {
            SecondaryIndexBuilder builder = buildingSupport.getIndexBuildTask(baseCfs, groupedIndexes, sstables, false);
            AsyncPromise<Object> build = new AsyncPromise<>();
            CompactionManager.instance.submitIndexBuild(builder).addCallback(new FutureCallback<Object>()
            {
                @Override
                public void onFailure(Throwable t)
                {
                    logger.warn("Failed to incrementally build indexes {}", getIndexNames(groupedIndexes));
                    build.tryFailure(t);
                }

                @Override
                public void onSuccess(Object o)
                {
                    logger.info("Incremental index build of {} completed", getIndexNames(groupedIndexes));
                    build.trySuccess(o);
                }
            });
            futures.add(build);
        });

        // Finally wait for the index builds to finish
        FBUtilities.waitOnFutures(futures);
    }

    /**

View on GitHub (pinned to 88fd0f6a0e)