apache/cassandra · warning

out of order partition (or partitions without of order…

Error message

%d out of order partition (or partitions without of order rows) found while scrubbing %s; Those have been written (in order) to a new sstable (%s)

What it means

After scrubbing, writeOutOfOrderPartitions writes any partitions (or row groups) whose rows were out of order into a separate, correctly ordered sstable, then warns the operator with the count, source sstable, and destination sstable. This keeps data that could not legally live in the main scrubbed output without discarding it.

Solutions

1. No action strictly needed: the out-of-order data was preserved in the new sstable named in the message
2. Run nodetool repair to reconcile the node's data with other replicas
3. Check the Cassandra version history for known ordering bugs if this recurs on newly written sstables
4. Verify application writes are not bypassing the normal write path (no manual sstable injection)

// Post-scrub hook:
if (scrubReport.outOfOrderCount > 0) { scheduleRepair(); verifyNewSstablePresent(); }

When it happens

Trigger: nodetool scrub detects outOfOrder entries (populated via saveOutOfOrderPartition or rows-out-of-order detection) and calls writeOutOfOrderPartitions to serialize them into a new sstable during scrub.

Common situations: Corruption or old bugs that wrote partitions/rows in wrong comparator order; sstables written by a defective earlier version; manually edited or improperly copied sstables.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• Out of order partition detected
• Duplicate row detected in
• Out of order rows found in partition
• Data file partition position
• Data file partition position

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

Appendix: source

Thrown at src/java/org/apache/cassandra/io/sstable/format/SortedTableScrubber.java:252

                outputHandler.output("Scrub of %s complete; looks like all %d partitions were tombstoned", sstable, emptyPartitions);
        }
    }

    private SSTableReader writeOutOfOrderPartitions(StatsMetadata metadata)
    {
        // out of order partitions/rows, but no bad partition found - we can keep our repairedAt time
        long repairedAt = badPartitions > 0 ? ActiveRepairService.UNREPAIRED_SSTABLE : sstable.getSSTableMetadata().repairedAt;
        SSTableReader newInOrderSstable;
        try (SSTableWriter inOrderWriter = CompactionManager.createWriter(cfs, destination, expectedBloomFilterSize, repairedAt, metadata.pendingRepair, metadata.isTransient, sstable, transaction))
        {
            for (Partition partition : outOfOrder)
                inOrderWriter.append(partition.unfilteredIterator());
            inOrderWriter.setRepairedAt(-1);
            inOrderWriter.setMaxDataAge(sstable.maxDataAge);
            newInOrderSstable = inOrderWriter.finish(true);
        }
        transaction.update(newInOrderSstable, false);
        outputHandler.warn("%d out of order partition (or partitions without of order rows) found while scrubbing %s; " +
                           "Those have been written (in order) to a new sstable (%s)", outOfOrder.size(), sstable, newInOrderSstable);
        return newInOrderSstable;
    }

    protected abstract UnfilteredRowIterator withValidation(UnfilteredRowIterator iter, String filename);

    @Override
    @VisibleForTesting
    public ScrubResult scrubWithResult()
    {
        scrub();
        return new ScrubResult(goodPartitions, badPartitions, emptyPartitions);
    }

    @Override
    public CompactionInfo.Holder getScrubInfo()
    {
        return scrubInfo;

View on GitHub (pinned to 88fd0f6a0e)