What causes "{} could not replay save point {}" in apache/cassandra?

Rely on full journal replay (automatic fallback) - startup continues

{} could not replay save point {}

Error message

{} could not replay save point {}

What it means

Replaying an on-disk save point (progress_log, range_index, redundant_before files) failed with an exception, so the loader logs the warning and returns null, falling back to replaying the full journal instead of starting from the save point. This is a performance degradation signal, not fatal.

Source

Thrown at src/java/org/apache/cassandra/service/accord/AccordCommandStore.java:973

            RedundantBefore rdb;
            try
            {
                logger.info("{} loading state from {}", this, savePoint);
                mxd = readOne(new File(savePoint, "max_decidedrx"), maxDecidedRX);
                mxc = readOne(new File(savePoint, "max_conflicts"), maxConflicts);
                {
                    File rjbf = new File(savePoint, "reject_before");
                    if (rjbf.exists())
                        mxc = mxc.with(readOne(rjbf, rejectBefore));
                }
                dll = readList(new File(savePoint, "listeners"), txnListener);
                dpl = readList(new File(savePoint, "progress_log"), progressLogState);
                rgi = rangeIndex.load(new File(savePoint, "range_index"));
                rdb = readOne(new File(savePoint, "redundant_before"), redundantBefore);
            }
            catch (Throwable t)
            {
                logger.warn("{} could not replay save point {}", this, savePoint, t);
                return null;
            }

            if (journal instanceof AccordJournal && ((AccordJournal)journal).maxDescriptor() <= segment)
                Invariants.expect(rdb.equals(unsafeGetRedundantBefore()));

            rangeIndex.restore(rgi);
            unsafeSetMaxDecidedRX(mxd);
            unsafeSetMaxConflicts(mxc);
            ((DefaultLocalListeners) listeners).restore(dll);
            boolean unsetCatchup = ((DefaultProgressLog) progressLog).setModeExclusive(safeStore, CATCH_UP);
            ((DefaultProgressLog) progressLog).restore(safeStore, dpl);
            if (unsetCatchup)
                ((DefaultProgressLog) progressLog).unsetModeExclusive(CATCH_UP);
            return Map.entry(id, segment + 1);
        });
    }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Rely on full journal replay (automatic fallback) - startup continues
Check disk/filesystem health for the savepoint directory
Delete the corrupt save point so future checkpoints are written cleanly (after backup)

Defensive patterns

Strategy: fallback

Validate before calling

// check savepoint files are readable before store load
File f = new File(savePoint, "progress_log");
if (!f.canRead()) log.warn("save point unreadable, full replay expected");

Try / catch

catch (Throwable t) { /* accept null return; startup falls back to full journal replay */ }

Prevention

Monitor filesystem health of the accord journal directory
Avoid deleting save point files manually
Use fsync-safe backups of the data directory

When it happens

Trigger: Loading an AccordCommandStore from a save point directory where any of progress_log, range_index, or redundant_before files is corrupt, truncated, unreadable, or fails deserialization.

Common situations: Corrupted or partially-written save point files after a crash; disk errors; save point deleted mid-replay; permission problems on the journal directory.

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/ff30463aa80dbb2f. Report an issue: GitHub.