apache/cassandra · warning

An error occurred while scrubbing the partition with key '%s

Error message

An error occurred while scrubbing the partition with key '%s' for an index table. Scrubbing will abort for this table and the index will be rebuilt.

What it means

When scrubbing an SSTable-backed 2i (index) table hits an unrecoverable per-partition error, BtiTableScrubber.throwIfCannotContinue logs this warning, aborts the scrub for that index table by throwing IOError, and relies on the index being rebuilt instead of failing the whole scrub session. Unlike a base-table scrub (which delegates to the parent's handling), index scrub failures are treated as recoverable via rebuild.

Source

Thrown at src/java/org/apache/cassandra/io/sstable/format/bti/BtiTableScrubber.java:293

            {
                indexIterator.advance();
            }
            catch (Throwable th)
            {
                outputHandler.warn(th, "Failed to go to the next entry in index");
                throw Throwables.cleaned(th);
            }
        }

        return false;
    }

    @Override
    protected void throwIfCannotContinue(DecoratedKey key, Throwable th)
    {
        if (isIndex)
        {
            outputHandler.warn("An error occurred while scrubbing the partition with key '%s' for an index table. " +
                               "Scrubbing will abort for this table and the index will be rebuilt.", keyString(key));
            throw new IOError(th);
        }

        super.throwIfCannotContinue(key, th);
    }

    @Override
    public void close()
    {
        fileAccessLock.writeLock().lock();
        try
        {
            FileUtils.closeQuietly(dataFile);
            FileUtils.closeQuietly(indexIterator);
        }
        finally
        {

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Rebuild the index (nodetool rebuild_index or drop and re-create the index) instead of recovering the corrupt index sstable
  2. Check the base table data is intact — the index can be safely regenerated from it
  3. Verify disk health; repeated index corruption suggests failing storage

Example fix

// before: fighting the corrupt index sstable
$ nodetool scrub ks tbl  // aborts on index table
// after
$ nodetool rebuild_index ks tbl idx_name  // index rebuilt from base data
Defensive patterns

Strategy: fallback

Validate before calling

// scrub index tables only after confirming base table integrity
boolean baseIntact = ColumnFamilyStore.getIfExists(keyspace, baseTable) != null
        && ColumnFamilyStore.getIfExists(keyspace, baseTable).getLiveSSTables().size() > 0;
if (!baseIntact) throw new IllegalStateException("Base table missing or empty; rebuild index from base data instead of scrubbing index sstables");

Try / catch

try {
    ColumnFamilyStore indexCfs = ...;
    indexCfs.scrub(...);
} catch (IOError e) {
    logger.warn("Index scrub aborted; rebuilding index {}", indexCfs, e);
    indexCfs.indexManager().rebuildIndexesBlocking(Set.of(indexName));
}

Prevention

When it happens

Trigger: scrubInternal on an is index table calls throwIfCannotContinue(key, th) after an unrecoverable read error on a partition key — e.g. corrupt data in an SSTableAttachedSecondaryIndex (SAI/2i) backing sstable.

Common situations: Corrupted secondary-index sstables after crashes or disk errors; running nodetool scrub on a node with damaged index files; index and base table out of sync after failed compactions.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors


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