What causes "Type %s already exists in %s" in apache/cassandra?

Use CREATE TYPE IF NOT EXISTS so existing types are skipped (ignoreIfExists=true)

apache/cassandra · error · ConfigurationException

Type already exists in

Error message

Type %s already exists in %s

What it means

Thrown as a ConfigurationException by a CreateTypes schema transformation when a UDT with the same name already exists in the keyspace and ignoreIfExists is false. Ensures duplicate user-defined type declarations fail loudly rather than being silently replaced.

Solutions

Use CREATE TYPE IF NOT EXISTS so existing types are skipped (ignoreIfExists=true)
Query system_schema.types for the keyspace to confirm the type name is free
Catch ConfigurationException and skip if the type definition matches expectations
Rename the new UDT if it is intended to be a distinct type

Example fix

// before
CREATE TYPE my_ks.address (street text, city text);
// after
CREATE TYPE IF NOT EXISTS my_ks.address (street text, city text);

Defensive patterns

Strategy: try-catch

Validate before calling

Types existing = Schema.instance.getKeyspaceMetadata(ksName).types; boolean has = existing.containsType(typeName);

Type guard

boolean typeExists(String ks, String t) { KeyspaceMetadata k = Schema.instance.getNullableKeyspaceMetadata(ks); return k != null && k.types.containsType(t); }

Try / catch

try { schemaChange(createTypeCql); } catch (ConfigurationException e) { if (!e.getMessage().contains("already exists")) throw e; }

Prevention

Use CREATE TYPE IF NOT EXISTS
Declare types in one shared bootstrap script applied once
Check system_schema.types before creating types
Order type creation: dependencies before dependents

When it happens

Trigger: Applying SchemaTransformations.createTypes(keyspaceName, types, ignoreIfExists=false) when Types.containsType(type.name) is true — e.g. CREATE TYPE without IF NOT EXISTS for an existing UDT.

Common situations: Replaying DDL scripts that declare CREATE TYPE without IF NOT EXISTS; migration tools re-registering types; multi-tenant setup scripts run repeatedly.

Understand the failure class

Background: "already exists" / EEXIST / FileAlreadyExistsException: what the 'file already exists' error means and how to fix it — this error's family across 37 libraries.

Related errors

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

Appendix: source

Thrown at src/java/org/apache/cassandra/schema/SchemaTransformations.java:139

            {
                Keyspaces schema = metadata.schema.getKeyspaces();
                if (toAdd.isEmpty())
                    return schema;

                String keyspaceName = toAdd.iterator().next().keyspace;
                KeyspaceMetadata keyspace = schema.getNullable(keyspaceName);
                if (null == keyspace)
                    throw invalidRequest("Keyspace '%s' doesn't exist", keyspaceName);

                Types types = keyspace.types;
                for (UserType type : toAdd)
                {
                    if (types.containsType(type.name))
                    {
                        if (ignoreIfExists)
                            continue;

                        throw new ConfigurationException("Type " + type + " already exists in " + keyspaceName);
                    }

                    types = types.with(type);
                }
                return schema.withAddedOrReplaced(keyspace.withSwapped(types));
            }

            @Override
            public boolean compatibleWith(ClusterMetadata metadata)
            {
                return metadata.directory.commonSerializationVersion.isAtLeast(Version.V0);
            }
        };
    }

    /**
     * We have a set of non-local, distributed system keyspaces, e.g. system_traces, system_auth, etc.
     * (see {@link SchemaConstants#REPLICATED_SYSTEM_KEYSPACE_NAMES}), that need to be created on cluster initialisation,

View on GitHub (pinned to 88fd0f6a0e)