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
- Rebuild the index (nodetool rebuild_index or drop and re-create the index) instead of recovering the corrupt index sstable
- Check the base table data is intact — the index can be safely regenerated from it
- 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
- Treat index sstable corruption as expected: plan on rebuild_index rather than scrub recovery
- Keep base-table snapshots; indexes can always be regenerated from base data
- After crashes, run rebuild_index proactively if index sstables show checksum/IO errors
- Watch for repeated index corruption as a sign of failing disks
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
- Unrecoverable error while scrubbing %s.Scrubbing cannot cont
- A tombstone should not have a value
- Error occurred during scrubbing
- An error occurred while scrubbing the partition with key '%s
- An error occurred while scrubbing the partition with key '%s
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/ba3fac2cccf4448f.
Report an issue: GitHub.