apache/cassandra · error · IllegalArgumentException
No serializer exists for kind {kind}
Error message
No serializer exists for kind {kind} What it means
Each TxnCondition.Kind has an associated serializer; the Kind.serializer() switch returns it for known kinds and throws IllegalArgumentException for any other value, including future or corrupted kinds. Since Kind is an enum this normally signals deserialization of an unknown kind byte or code compiled against mismatched enum definitions.
Source
Thrown at src/java/org/apache/cassandra/service/accord/txn/TxnCondition.java:156
case IS_NOT_NULL:
case IS_NULL:
return Exists.serializer;
case EQUAL:
case NOT_EQUAL:
case LESS_THAN:
case LESS_THAN_OR_EQUAL:
case GREATER_THAN:
case GREATER_THAN_OR_EQUAL:
return Value.serializer;
case AND:
case OR:
return BooleanGroup.serializer;
case NONE:
return None.serializer;
case COLUMN_CONDITIONS:
return ColumnConditionsAdapter.serializer;
default:
throw new IllegalArgumentException("No serializer exists for kind " + this);
}
}
}
protected final Kind kind;
public TxnCondition(Kind kind)
{
this.kind = kind;
}
@Override
public boolean equals(Object o)
{
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
TxnCondition condition = (TxnCondition) o;
return kind == condition.kind;View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Align all nodes to the same build so the kind is defined on both ends.
- Inspect the kind value in the message to identify which newer constant is being sent.
- Add a serializer case for the new Kind in this build before accepting traffic from upgraded peers.
Defensive patterns
Strategy: try-catch
Validate before calling
// verify the kind is known to this build before decoding
int kindOrdinal = readKindOrdinal(payload);
if (kindOrdinal < 0 || kindOrdinal >= TxnCondition.Kind.values().length)
throw new IllegalArgumentException("Unknown TxnCondition kind: " + kindOrdinal); Try / catch
try {
ITxnConditionSerializer s = kind.serializer();
} catch (IllegalArgumentException e) {
logger.error("Unknown TxnCondition kind from peer - build mismatch?", e);
rejectMessage(peer); // do not partially deserialize
} Prevention
- Keep cluster builds homogeneous when adding enum constants
- Reject unknown kinds early instead of partial deserialization
- Add new kinds to all nodes before sending them
When it happens
Trigger: Calling Kind.serializer() on a Kind value not covered by the switch (any kind beyond the enumerated KNOWN/BOOLEAN_GROUP/NONE/COLUMN_CONDITIONS cases in this build).
Common situations: Wire payload produced by a newer build with an added TxnCondition.Kind; enum desynchronized between nodes during rolling upgrade; corrupted serialized transaction conditions.
Related errors
- Unknown kind: {kind}
- Unrecognized kind {kind}
- Transaction Statement is unsupported when migrating away fro
- UNSAFE_MIXED_MUTATIONS_MSG
- Accord transaction uses dropped tables
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/07da0a1b8f6f13b9.
Report an issue: GitHub.