Failed to update the distributed status of view, sleeping 5…

Error message

Failed to update the distributed status of view, sleeping 5 minutes before retrying

What it means

ViewBuilder.updateDistributed() writes the view build status to the distributed system keyspaces (successfulViewBuild in system_distributed and setViewBuiltReplicated in system local tables). If either write throws, it logs this warning and schedules itself to retry in 5 minutes, so the build's completion status is eventually recorded.

Solutions

Ensure the system_distributed keyspace exists with a replication factor achievable by the cluster (ALTER KEYSPACE system_distributed WITH replication = ...) and run repair on it
Wait for the automatic 5-minute retry — the status will be written once writes succeed
Check for schema disagreement (nodetool describecluster) and resolve it
Verify node connectivity and that all replicas for system_distributed are up

Defensive patterns

Strategy: retry

Validate before calling

// verify system_distributed keyspace before MV creation:
// SELECT keyspace_name FROM system_schema.keyspaces WHERE keyspace_name='system_distributed';
// ensure its RF <= number of DC-local nodes and it is repaired

Try / catch

try {
    updateDistributed();
} catch (Exception e) {
    // auto-retried after 5 minutes; fix system_distributed RF/connectivity in the meantime
}

Prevention

Set system_distributed RF to match per-DC node counts and repair it regularly
Keep system_distributed keyspace present (it can be missing after some migrations)
Resolve schema disagreements promptly
Monitor write failures against system keyspaces

When it happens

Trigger: start()/finish() call updateDistributed(); the writes to SystemDistributedKeyspace.successfulViewBuild or SystemKeyspace.setViewBuiltReplicated throw an Exception (e.g. the system_distributed keyspace/table unavailable, coordinator timeouts, consistency issues).

Common situations: system_distributed keyspace missing or having RF issues (common after misconfigured clusters or when RF exceeds available nodes); node cannot reach quorum for the status write; schema disagreements about system tables.

Related errors

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

Appendix: source

Thrown at src/java/org/apache/cassandra/db/view/ViewBuilder.java:226

    private void finish()
    {
        logger.debug("Marking view({}.{}) as built after covering {} keys ", ksName, view.name, keysBuilt);
        SystemKeyspace.finishViewBuildStatus(ksName, view.name);
        updateDistributed();
    }

    private void updateDistributed()
    {
        try
        {
            SystemDistributedKeyspace.successfulViewBuild(ksName, view.name, localHostId);
            SystemKeyspace.setViewBuiltReplicated(ksName, view.name);
        }
        catch (Exception e)
        {
            ScheduledExecutors.nonPeriodicTasks.schedule(this::updateDistributed, 5, TimeUnit.MINUTES);
            logger.warn("Failed to update the distributed status of view, sleeping 5 minutes before retrying", e);
        }
    }

    /**
     * Stops the view building.
     */
    void stop()
    {
        boolean wasStopped;
        synchronized (this)
        {
            wasStopped = isStopped;
            internalStop(false);
        }
        // TODO: very unclear what the goal is here. why do we wait only if we were the first to invoke stop?
        // but we wait outside the synchronized block to avoid a deadlock with `build` in the future callback
        if (!wasStopped)
            FBUtilities.waitOnFuture(future);

View on GitHub (pinned to 88fd0f6a0e)