apache/cassandra · error · ConfigurationException

Unsupported parameter '%s' for %s, supported parameters are

Error message

Unsupported parameter '%s' for %s, supported parameters are %s

What it means

IDefaultRoleInitializer.validateSupportedParams checks that every parameter given to a role-manager/authorizer implementation is one it declares as supported. An unknown key in the options map raises ConfigurationException naming the bad parameter, the class, and the supported set.

Source

Thrown at src/java/org/apache/cassandra/auth/IDefaultRoleInitializer.java:93

    /**
     * @return true if the cluster already has at least one role (or the configured default role specifically).
     * Implemented once, sealed, by {@link AbstractDefaultRoleInitializer} — see that class for the logic.
     */
    boolean hasExistingRoles();

    /**
     * @param manager manager to check the support of
     * @return true if this role initializer conceptually works together with specified role manager, false otherwise
     */
    boolean supportsRoleManager(IRoleManager manager);

    static void validateSupportedParams(Map<String, String> parameters, Set<String> supportedParams, Class<?> implClass)
    {
        for (String param : parameters.keySet())
        {
            if (!supportedParams.contains(param))
                throw new ConfigurationException(String.format("Unsupported parameter '%s' for %s, supported parameters are %s",
                                                               param, implClass.getSimpleName(), supportedParams));
        }
    }
}

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Compare the reported parameter name against the supported set printed in the message and fix or remove it from the configuration
Check the class's supportedParams set for the exact spelling after a version upgrade
Remove stale options left over from a previous auth implementation

Example fix

// before
role_manager:
  class_name: CassandraRoleManager
  options:
    rolenames_limit: 10
// after
role_manager:
  class_name: CassandraRoleManager
  options:
    consistency_level: QUORUM

Defensive patterns

Strategy: validation

Validate before calling

Set<String> supported = Set.of("consistency_level", "roles_cache_max_entries");
parameters.keySet().stream().filter(k -> !supported.contains(k))
    .forEach(k -> System.err.println("Unknown role-manager option: " + k));

Try / catch

try { configureRoleManager(params); } catch (ConfigurationException e) { log.error("fix cassandra.yaml role_manager options: {}", e.getMessage()); }

Prevention

Copy option keys only from the target class's documented supportedParams set
Re-validate auth config after Cassandra upgrades (options get renamed/removed)
Don't share an options block between authorizer and role manager configs

When it happens

Trigger: Configuring a role manager (e.g. in cassandra.yaml: role_manager with options) or CassandraRoleManager/defaults with a typo'd or renamed option key, e.g. passing 'replication_factor' style legacy keys to an implementation that no longer accepts them.

Common situations: Upgrading Cassandra where an option was renamed or removed; copying configuration between CassandraAuthorizer and CassandraRoleManager whose supported option sets differ; typos in cassandra.yaml options blocks.

Related errors

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