apache/cassandra · critical · CorruptSSTableException

CorruptSSTableException wrapping…

Error message

CorruptSSTableException wrapping IndexOutOfBoundsException|VIntOutOfRangeException|AssertionError for ${filename}

What it means

SSTableIdentityIterator.hasNext() guards against in-band corruption signs: IndexOutOfBoundsException, VIntOutOfRangeException, and AssertionError thrown while parsing rows are converted to CorruptSSTableException with the sstable filename after marking the sstable suspect. These exception types indicate the byte stream does not match the expected row layout rather than a low-level I/O failure.

Solutions

Scrub the affected table with `nodetool scrub` so the corrupt partition is dropped or rewritten
Run `nodetool repair` to repopulate the lost data from healthy replicas, or restore from backup
Check whether the sstable was written by a different Cassandra version and run `nodetool upgradesstables` if needed
Verify disk health and re-checksum copied sstable files; replace failing hardware

Example fix

// before: retrying reads of the same corrupt sstable
// after: scrub and repair
nodetool scrub -- keyspace table
nodetool repair -- keyspace table

Defensive patterns

Strategy: try-catch

Validate before calling

// detect likely corruption before full reads
// run sstablemetadata / nodetool verify on the sstable ahead of application reads
boolean verified = verifySstable(filename); // invoke sstableverify out-of-band

Try / catch

try {
    while (iter.hasNext()) { consume(iter.next()); }
} catch (CorruptSSTableException e) {
    logger.error("Corrupt sstable {} during iteration", e.getPath(), e);
    // retry read against a healthy replica; queue table for scrub
}

Prevention

Keep cluster versions aligned; upgradesstables after upgrades
Use error-correcting storage (ECC RAM, healthy disks)
Avoid manual copying of sstable data files
Run periodic repairs to detect and fix divergent replicas
Alert on CorruptSSTableException in logs

When it happens

Trigger: Calling hasNext() on a partially-read SSTableIdentityIterator when the underlying SSTableSimpleIterator misparses data: an out-of-bounds read from a truncated cell, an oversized/invalid VInt encoded length, or an assertion about row structure failing.

Common situations: SSTables written by an incompatible Cassandra version; bit-flip corruption on disk; files truncated mid-row by a crash or bad copy; manually edited or patched sstable bytes; corrupted compressed chunks.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors

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

Appendix: source

Thrown at src/java/org/apache/cassandra/io/sstable/SSTableIdentityIterator.java:195

    {
        return partitionLevelDeletion;
    }

    public Row staticRow()
    {
        return staticRow;
    }

    public boolean hasNext()
    {
        try
        {
            return iterator.hasNext();
        }
        catch (IndexOutOfBoundsException | VIntOutOfRangeException | AssertionError e)
        {
            sstable.markSuspect();
            throw new CorruptSSTableException(e, filename);
        }
        catch (CorruptSSTableException e) // to ensure that we marked the sstable as suspected if CorruptSSTableException is thrown from lower levels
        {
            sstable.markSuspect();
            throw e;
        }
        catch (IOError e)
        {
            if (e.getCause() instanceof IOException)
            {
                sstable.markSuspect();
                throw new CorruptSSTableException((Exception)e.getCause(), filename);
            }
            else
            {
                throw e;
            }
        }

View on GitHub (pinned to 88fd0f6a0e)