apache/cassandra · error · SSTableAcquisitionException

Prepare phase for incremental repair session %s has failed b

Error message

Prepare phase for incremental repair session %s has failed because it encountered intersecting sstables belonging to another incremental repair session (%s). This is caused by starting an incremental repair session before a previous one has completed. Check nodetool repair_admin for hung sessions and fix them.

What it means

Incremental repair requires that sstables intersecting the repair range belong to no other unfinished repair session. When the prepare phase finds an intersecting sstable whose pendingRepair id belongs to another session that is not finalized, it throws SSTableAcquisitionException with this message indicating an overlapping incremental repair was started before the previous one completed.

Source

Thrown at src/java/org/apache/cassandra/db/repair/PendingAntiCompaction.java:146

            if (!sstable.descriptor.version.hasPendingRepair())
            {
                String message = String.format("Prepare phase failed because it encountered legacy sstables that don't " +
                                               "support pending repair, run upgradesstables before starting incremental " +
                                               "repairs, repair session (%s)", prsid);
                throw new SSTableAcquisitionException(message);
            }

            // exclude sstables pending repair, but record session ids for
            // non-finalized sessions for a later error message
            if (metadata.pendingRepair != NO_PENDING_REPAIR)
            {
                if (!ActiveRepairService.instance().consistent.local.isSessionFinalized(metadata.pendingRepair))
                {
                    String message = String.format("Prepare phase for incremental repair session %s has failed because it encountered " +
                                                   "intersecting sstables belonging to another incremental repair session (%s). This is " +
                                                   "caused by starting an incremental repair session before a previous one has completed. " +
                                                   "Check nodetool repair_admin for hung sessions and fix them.", prsid, metadata.pendingRepair);
                    throw new SSTableAcquisitionException(message);
                }
                return false;
            }
            Collection<CompactionInfo> cis = CompactionManager.instance.active.getCompactionsForSSTable(sstable, OperationType.ANTICOMPACTION);
            if (cis != null && !cis.isEmpty())
            {
                // todo: start tracking the parent repair session id that created the anticompaction to be able to give a better error messsage here:
                StringBuilder sb = new StringBuilder();
                sb.append("Prepare phase for incremental repair session ");
                sb.append(prsid);
                sb.append(" has failed because it encountered intersecting sstables belonging to another incremental repair session. ");
                sb.append("This is caused by starting multiple conflicting incremental repairs at the same time. ");
                sb.append("Conflicting anticompactions: ");
                for (CompactionInfo ci : cis)
                    sb.append(ci.getTaskId() == null ? "no compaction id" : ci.getTaskId()).append(':').append(ci.getSSTables()).append(',');
                throw new SSTableAcquisitionException(sb.toString());
            }
            return true;

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Run 'nodetool repair_admin list' to find hung sessions and 'nodetool repair_admin cleanup' (fail the sessions) for stale ones
  2. Wait for the current incremental repair to complete before starting another on overlapping ranges
  3. Fix scheduling so incremental repairs over the same ranges never overlap
  4. After cleanup, re-run the repair; consider full (non-incremental) repair to reset pendingRepair state if sessions are badly stuck

Example fix

// before
nodetool repair -inc ks   # previous session still hung
// after
nodetool repair_admin list
nodetool repair_admin cleanup --force
nodetool repair -inc ks
Defensive patterns

Strategy: validation

Validate before calling

// shell: check for un-finalized sessions before starting repair
nodetool repair_admin list

Try / catch

try { repairService.submitIncremental(); } catch (Exception e) { if (e.getMessage().contains("another incremental repair session")) { cleanupHungSessions(); retry(); } else throw e; }

Prevention

When it happens

Trigger: Starting a new incremental repair on a token range while a previous incremental repair session over the same range is still running or hung (never finalized); crashed repair sessions leaving sstables with dangling pendingRepair ids.

Common situations: Overlapping scheduled repairs (e.g. cron firing while a manual repair runs); hung repair sessions after node restarts/failures; repair timeouts leaving unfinalized sessions.

Related errors


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