apache/cassandra · warning · RepairException

An incremental repair with session id {id} finished during t

Error message

An incremental repair with session id {id} finished during this preview repair runtime

What it means

During a preview (or advisory) repair, if an intersecting incremental repair session finishes while the preview is running, the preview result becomes unreliable (the IR state it was reading changed underneath it). The session force-shuts-down and fails with this RepairException.

Source

Thrown at src/java/org/apache/cassandra/repair/RepairSession.java:466

        Exception exception = new IOException(String.format("Endpoint %s died", endpoint));
        logger.error("{} session completed with the following error", previewKind.logPrefix(getId()), exception);
        // If a node failed, we stop everything (though there could still be some activity in the background)
        forceShutdown(exception);
    }

    public void onIRStateChange(LocalSession session)
    {
        // we should only be registered as listeners for PreviewKind.REPAIRED, but double check here
        if (previewKind == PreviewKind.REPAIRED &&
            session.getState() == ConsistentSession.State.FINALIZED &&
            includesTables(session.tableIds))
        {
            for (Range<Token> range : session.ranges)
            {
                if (range.intersects(ranges()))
                {
                    logger.warn("{} An intersecting incremental repair with session id = {} finished, preview repair might not be accurate", previewKind.logPrefix(getId()), session.sessionID);
                    forceShutdown(RepairException.warn("An incremental repair with session id "+session.sessionID+" finished during this preview repair runtime"));
                    return;
                }
            }
        }
    }

    public boolean accordOnly()
    {
        return repairData && repairAccord && !repairPaxos;
    }

    private boolean includesTables(Set<TableId> tableIds)
    {
        Keyspace ks = Keyspace.open(state.keyspace);
        if (ks != null)
        {
            for (String table : state.cfnames)
            {

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Re-run the preview repair after the incremental repair has fully finished.
Serialize repair scheduling so incremental and preview repairs don't overlap on the same ranges.
Check repair history (nodetool remedy / repair service logs) to see which IR session raced.
Use incremental repair's own preview (advise vs validate) appropriately: preview kinds that check IR state expect no concurrent IR.
If recurring, fix overlapping cron/automation for repairs.

Defensive patterns

Strategy: retry

Validate before calling

// Check active/finished incremental repairs before previewing:
// SELECT * FROM system.repairs WHERE state != 'COMPLETED';
// nodetool adaptations: ensure no overlapping repair runs

Try / catch

try {
    previewRepair(keyspace, previewKind);
} catch (RepairException e) {
    if (e.getMessage().contains("finished during this preview repair runtime")) {
        // wait for IR completion, then re-run preview
    }
}

Prevention

Serialize preview and incremental repair schedules on the same keyspaces.
Gate repair automation on system.repairs state.
Avoid overlapping repair jobs from multiple schedulers.
Re-run preview after any concurrent IR finishes; results are otherwise unreliable.

When it happens

Trigger: onIRStateChange detects a completed incremental repair session whose ranges intersect the preview repair's ranges; the preview coordinator then calls forceShutdown with a RepairException.

Common situations: Operators run a preview repair while an incremental repair (started by a schedule or another operator) completes concurrently; overlapping repair schedules in the same keyspace.

Related errors

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