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
- Check the propagated Throwable on the returned future / subsequent 'Index build of {} failed' log to find the root cause.
- Run nodetool rebuild_index (or REBUILD INDEX) on the affected indexes to retry from scratch.
- If caused by concurrent compaction, retry after compaction pressure subsides.
- 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
- Avoid creating indexes during heavy compaction windows.
- Ensure enough disk headroom for both compaction and index build output.
- Monitor background build futures and automate rebuild_index on failure.
- Don't stop nodes mid-build; use nodetool compactionstats to check in-flight index builds.
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
- 0x0000
- Aborted garbage collection for at least one table in…
- Aborted garbage collection for at least one table, check…
- Aborting index memtable flush for
- An error occurred while scrubbing the partition with key
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)