apache/cassandra · warning

Not adding view {} because the base table {} is unknown

Error message

Not adding view {} because the base table {} is unknown

What it means

ViewManager.addView() registers a materialized view with its keyspace, but needs the base table's ColumnFamilyStore to exist locally. Due to schema propagation timing (CASSANDRA-13737), the view definition can arrive before its base table; in that case the view is skipped with this warning. ViewManager.reload()/update schemes re-add the view later once the base table appears.

Source

Thrown at src/java/org/apache/cassandra/db/view/ViewManager.java:176

            logger.info("Not submitting build tasks for views in keyspace {} as " +
                        "storage service is not initialized", keyspace.getName());
            return;
        }

        for (View view : allViews())
        {
            view.build();
            // We provide the new definition from the base metadata
            view.updateDefinition(newViewsByName.get(view.name));
        }
    }

    public void addView(ViewMetadata definition)
    {
        // Skip if the base table doesn't exist due to schema propagation issues, see CASSANDRA-13737
        if (!keyspace.hasColumnFamilyStore(definition.baseTableId))
        {
            logger.warn("Not adding view {} because the base table {} is unknown",
                        definition.name(),
                        definition.baseTableId);
            return;
        }

        View view = new View(definition, keyspace.getColumnFamilyStore(definition.baseTableId));
        forTable(keyspace.getMetadata().tables.getNullable(view.getDefinition().baseTableId)).add(view);
        viewsByName.put(definition.name(), view);
    }

    /**
     * Stops the building of the specified view, no-op if it isn't building.
     *
     * @param name the name of the view
     */
    public void dropView(String name)
    {
        View view = viewsByName.remove(name);

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. No action needed if transient: the next schema reload adds the view once the base table exists — verify with a schema describe
2. Force a schema refresh (nodetool reload with schema round) or restart the node if the view remains missing
3. Check schema agreement across nodes (nodetool describecluster) and repair system_schema on lagging nodes
4. If persistently missing, recreate the materialized view after confirming the base table exists everywhere

// after creating an MV, verify registration on every node:
// nodetool describecluster (schema agreement)
// confirm base table exists: DESC KEYSPACE <ks>;

if (!keyspace.hasColumnFamilyStore(baseTableId)) {
    // view will be added on next schema reload; verify it appears
    // otherwise restart node / refresh schema
}

When it happens

Trigger: addView(definition) is invoked during schema reload while keyspace.hasColumnFamilyStore(definition.baseTableId) is false — the view's schema row arrived before the base table's schema row.

Common situations: Schema changes racing across the cluster (view created moments before base table row is applied locally); restoring schema partially; multi-DC clusters with slow schema propagation; CASSANDRA-13737-class timing issues.

Related errors

• Failed to get schema to converge before building view {}.{}
• Load CIDR groups cache operation not supported by %s
• 'Get CIDR groups for IP' operation not supported by %s
• ACCESS TO DATACENTERS operations not supported by AllowAllNe
• Remote configuration of auth caches is disabled

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