apache/cassandra · warning

Partition denylist table metadata not found

Error message

Partition denylist table metadata not found

What it means

PartitionDenylist.checkDenylistNodeAvailability logs this warning when the partition_denylist table metadata is missing from the system_distributed keyspace. The method returns false, so denylist loads/refreshes are skipped rather than failing.

Source

Thrown at src/java/org/apache/cassandra/schema/PartitionDenylist.java:174

        {
            logger.error("Failed to load partition denylist", tr);
            retryReason = "Exception";
        }

        // This path will also be taken on other failures other than UnavailableException,
        // but seems like a good idea to retry anyway.
        int retryInSeconds = DatabaseDescriptor.getDenylistInitialLoadRetrySeconds();
        logger.info("{} while loading partition denylist cache. Scheduled retry in {} seconds.", retryReason, retryInSeconds);
        ScheduledExecutors.optionalTasks.schedule(this::initialLoad, retryInSeconds, TimeUnit.SECONDS);
    }

    private boolean checkDenylistNodeAvailability()
    {
        TableMetadata denyListTable = ClusterMetadata.current().schema.getKeyspaceMetadata(SystemDistributedKeyspace.NAME)
                                                              .getTableOrViewNullable(SystemDistributedKeyspace.PARTITION_DENYLIST_TABLE);
        if (denyListTable == null)
        {
            logger.warn("Partition denylist table metadata not found");
            return false;
        }

        boolean sufficientNodes = RangeCommands.sufficientLiveNodesForSelectStar(denyListTable, DatabaseDescriptor.getDenylistConsistencyLevel());
        if (!sufficientNodes)
        {
            AVAILABILITY_LOGGER.warn("Attempting to load denylist and not enough nodes are available for a {} refresh. Reload the denylist when unavailable nodes are recovered to ensure your denylist remains in sync.",
                                     DatabaseDescriptor.getDenylistConsistencyLevel());
        }
        return sufficientNodes;
    }

    /** Helper method as we need to both build cache on initial init but also on reload of cache contents and params */
    private LoadingCache<TableId, DenylistEntry> buildEmptyCache()
    {
        // We rely on details of .refreshAfterWrite to reload this async in the background when it's hit:
        // https://github.com/ben-manes/caffeine/wiki/Refresh
        return Caffeine.newBuilder()

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Ensure schema is fully agreed cluster-wide (nodetool describecluster) and the denylist migration/table creation has executed
  2. Manually verify the table exists: DESCRIBE TABLE system_distributed.partition_denylist; create per upgrade instructions if absent
  3. Restart the node after schema converges so ClusterMetadata reloads the table
  4. Check for schema pull failures in logs (schema disagreement during rolling upgrade)
Defensive patterns

Strategy: validation

Validate before calling

// check table exists before denylist ops
boolean denylistTableReady =
    ClusterMetadata.current().schema.getKeyspaceMetadata(SystemDistributedKeyspace.NAME) != null &&
    ClusterMetadata.current().schema.getKeyspaceMetadata(SystemDistributedKeyspace.NAME)
        .getTableOrViewNullable(SystemDistributedKeyspace.PARTITION_DENYLIST_TABLE) != null;

Type guard

boolean denylistTablePresent(KeyspaceMetadata ks) {
    return ks != null && ks.getTableOrViewNullable(SystemDistributedKeyspace.PARTITION_DENYLIST_TABLE) != null;
}

Try / catch

if (!denylistTablePresent(...)) { skipDenylistLoad(); return; } // matching built-in fallback

Prevention

When it happens

Trigger: Any denylist operation (initialLoad, load, reload, getDenylistForAllTablesFromCQL, refreshTableDenylist) when ClusterMetadata schema lacks the PARTITION_DENYLIST_TABLE — typically before upgrade/migration created it.

Common situations: Upgraded clusters where the denylist table creation did not run; schema disagreement preventing the table from propagating; nodes started before schema fully synced.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


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