apache/cassandra · error
Stopping log processing on the node... All subsequent…
Error message
Stopping log processing on the node... All subsequent epochs will be ignored.
What it means
LocalLog's async follower thread catches StopProcessingException thrown by a transformation when the node must stop applying cluster metadata log entries. It logs this warning, shuts down the log executor, and thereafter ignores all subsequent epochs: the node has left the metadata log-processing path (e.g. after being removed from the cluster or hitting an unrecoverable state).
Solutions
- Read the attached StopProcessingException stack to learn why processing stopped.
- If the node was removed, shut it down; a removed node must not keep serving.
- If it was an unexpected stop, restart the node so LocalLog is rebuilt (or re-bootstrap it).
- Compare the node's last committed epoch with the CMS to detect divergence and rejoin if needed.
Defensive patterns
Strategy: retry
Validate before calling
// Check whether the node is still a metadata member before applying entries
if (!ClusterMetadataService.instance().isCurrent() && !isMemberOfCluster(metadata)) {
throw new StopProcessingException("Node no longer member of cluster");
} Try / catch
try {
processCommitted(metadata);
} catch (StopProcessingException e) {
logger.warn("Halting log catch-up; node must rejoin or shut down", e);
} Prevention
- Shut down nodes immediately after decommission/removal.
- Keep cluster versions consistent to avoid unprocessable transformations.
- Alert on this log line - it means permanent halt of local log processing.
When it happens
Trigger: A transformation applied while catching up on the log throws StopProcessingException - typically because the node's metadata state diverged, the node was decommissioned/removed, or the log contains an entry the local node cannot process; LocalLog.Async then stops processing permanently.
Common situations: Node removed from the cluster but still running and consuming the log; failed/incompatible transformation after an upgrade; internal error forcing TCM to halt local log catch-up; nodes left running after decommission.
Understand the failure class
Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.
Related errors
- Error in log follower
- Addresses differ: !=
- Bad CMS state:
- Bad NodeState
- Booting with ClusterMetadata from file:
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/3aa21cc573c6ccb1.
Report an issue: GitHub.
Appendix: source
Thrown at src/java/org/apache/cassandra/tcm/log/LocalLog.java:851
{
Condition condition = subscriber.getAndSet(null);
// Grab a ticket ahead of time, so that we can't get into race with the exit from process pending
signal = logNotifier.register();
processPendingInternal();
if (condition != null)
condition.signalAll();
// if no new threads have subscribed since we started running, await
// otherwise, run again to process whatever work they may be waiting on
if (subscriber.get() == null)
{
signal.await();
signal = null;
}
}
}
catch (StopProcessingException t)
{
logger.warn("Stopping log processing on the node... All subsequent epochs will be ignored.", t);
executor.shutdown();
}
catch (InterruptedException t)
{
// ignore
}
catch (Throwable t)
{
// TODO handle properly
logger.warn("Error in log follower", t);
}
finally
{
// If signal was not consumed for some reason, cancel it
if (signal != null)
signal.cancel();
}
}View on GitHub (pinned to 88fd0f6a0e)