apache/cassandra · warning

Stop marker is older than start marker ({}<{}), so cannot as

Error message

Stop marker is older than start marker ({}<{}), so cannot assume we have a complete log of our votes in any consensus groups. Continuing to startup as configured.

What it means

On Accord startup, the journal's stop marker is older than the start marker, so a complete log of votes cannot be assumed. Depending on stopMarkerFailurePolicy the node either exits, logs this warning and continues (unsafe startup), or rebootstraps.

Source

Thrown at src/java/org/apache/cassandra/service/accord/AccordService.java:553

    {
        if (state != State.INIT)
            return;

        boolean rebootstrap = false;
        {
            long startMarker = ReplayMarkers.readStartMarker();
            long stopMarker = ReplayMarkers.readStopMarker();
            if (stopMarker < startMarker)
            {
                switch (getAccord().journal.stopMarkerFailurePolicy)
                {
                    default: throw new UnhandledEnum(getAccord().journal.stopMarkerFailurePolicy);
                    case EXIT:
                        throw new RuntimeException("Stop marker is older than start marker (" + stopMarker + '<' + startMarker + ") , so cannot assume we have a complete log of our votes in any consensus groups. Exiting.");

                    case ALLOW_UNSAFE_STARTUP:
                    case UNSAFE_STARTUP:
                        logger.warn("Stop marker is older than start marker ({}<{}), so cannot assume we have a complete log of our votes in any consensus groups. Continuing to startup as configured.", stopMarker, startMarker);
                        break;

                    case REBOOTSTRAP:
                        logger.info("Stop marker is older than start marker ({}<{}). Rebootstrapping.", stopMarker, startMarker);
                        rebootstrap = true;
                }
            }
        }

        logger.info("Starting background compaction of system_accord");
        // We control this ourselves to ensure it starts when we need it, as especially commands_for_key
        // can accumulate a lot of state and degrade replay performance significantly
        scheduler.recurring(() -> {
            CompactionManager.instance.submitBackground(AccordColumnFamilyStores.commandsForKey);
            CompactionManager.instance.submitBackground(AccordColumnFamilyStores.journal);
        }, 1L, MINUTES);

        long durabilityFlushIntervalNanos = DatabaseDescriptor.getAccordDurabilityFlushInterval(NANOSECONDS);

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Prefer exiting (policy EXIT) and restoring a consistent journal/data directory
  2. If data loss is acceptable, intentionally allow unsafe startup via stopMarkerFailurePolicy
  3. Choose REBOOTSTRAP policy to rejoin the node with a clean Accord state

Example fix

// before
accord.journal.stop_marker_failure_policy: ALLOW_UNSAFE_STARTUP
// after
accord.journal.stop_marker_failure_policy: REBOOTSTRAP
Defensive patterns

Strategy: validation

Validate before calling

// before starting, verify journal marker ordering from backups
if (stopMarker.compareTo(startMarker) < 0 && !allowUnsafe) throw new IllegalStateException("journal markers out of order; restore consistent backup");

Try / catch

catch (RuntimeException e) { /* choose EXIT/REBOOTSTRAP per stopMarkerFailurePolicy before continuing */ }

Prevention

When it happens

Trigger: localStartup reads start/stop markers from the Accord journal and finds stopMarker < startMarker (e.g. journal truncation, reverted/rolled-back data directory, restored backup).

Common situations: Restoring an older snapshot of the data directory over a newer journal; disk rollback after a crash; manual journal cleanup that removed newer segments; unsafe startup policy configured after failures.

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


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