apache/cassandra · error · UnsupportedOperationException

Because of this name: ${name} if you removed it from the yam

Error message

Because of this name: ${name} if you removed it from the yaml and are still seeing this, make sure to drop table

What it means

When building a column generator from the loaded schema metadata, the type switch only supports known Cassandra types (map, set, list, primitives, etc.). An unrecognized type falls through to this UnsupportedOperationException, whose message hints the user probably removed a column from the YAML but the table still contains it. The stress tool cannot generate data for the unsupported/removed type.

Source

Thrown at tools/stress/src/org/apache/cassandra/stress/StressProfile.java:849

                    return new Dates(name, config);
                case "UUID":
                    return new UUIDs(name, config);
                case "TIMEUUID":
                    return new TimeUUIDs(name, config);
                case "TINYINT":
                    return new TinyInts(name, config);
                case "SMALLINT":
                    return new SmallInts(name, config);
                case "TIME":
                    return new Times(name, config);
                case "DATE":
                    return new LocalDates(name, config);
                case "SET":
                    return new Sets(name, getGenerator(name, collectionType, null, config), config);
                case "LIST":
                    return new Lists(name, getGenerator(name, collectionType, null, config), config);
                default:
                    throw new UnsupportedOperationException("Because of this name: "+name+" if you removed it from the yaml and are still seeing this, make sure to drop table");
            }
        }
    }

    public static StressProfile load(URI file) throws IOError
    {
        try
        {
            Constructor constructor = new Constructor(StressYaml.class, YamlConfigurationLoader.getDefaultLoaderOptions());

            Yaml yaml = new Yaml(constructor);

            InputStream yamlStream = file.toURL().openStream();

            if (yamlStream.available() == 0)
                throw new IOException("Unable to load yaml file from: "+file);

            StressYaml profileYaml = yaml.loadAs(yamlStream, StressYaml.class);

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Drop the existing table so the schema matches the current YAML, then let stress recreate it
Add the column back to the profile YAML or declare it so a supported generator is chosen
Avoid unsupported column types (UDTs/custom types) in stress-managed tables
Recreate the keyspace/table to guarantee schema/YAML consistency

Example fix

// before: yaml no longer defines column 'oldcol' but table still has it
// after
// cqlsh> DROP TABLE ks.mytable; then re-run stress to recreate schema

Defensive patterns

Strategy: fallback

Validate before calling

// compare YAML columns to actual schema before running
Set<String> yamlCols = profileColumnNames();
Set<String> tableCols = metadata.getTable(...).getColumns().stream().map(ColumnMetadata::getName).collect(toSet());
if (!tableCols.equals(yamlCols)) throw new IllegalStateException("schema/YAML mismatch: " + tableCols);

Try / catch

try { new StressProfile...load(...); } catch (UnsupportedOperationException e) { if (e.getMessage().startsWith("Because of this name")) { log.error("Drop the stale table or restore the column"); throw e; } }

Prevention

DROP the table whenever you change profile column definitions
Avoid UDTs/custom types in stress-managed tables
Keep table schema and YAML in sync via the profile's schema creation step

When it happens

Trigger: StressProfile construction encountering a schema column whose type has no generator case, most often a leftover column in the actual table that is no longer declared/expected in the profile YAML (or a truly unsupported type like custom/UDT types).

Common situations: Changed the YAML column definitions but did not DROP the old table, so the schema still has columns the profile does not know; using exotic types (frozen UDTs, custom types) in the table.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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