apache/cassandra · error · MarshalException
Failure validating the %dth field
Error message
Failure validating the %dth field %s; %s
What it means
MarshalException wrapper from UserTypeSerializer.validate: the nested serializer for the named field rejected the value; the original MarshalException message and cause are chained into a message identifying the offending field index and name. It is a generic delegation guard, not an independent validation.
Solutions
- Read the chained cause message to find the actual field-level violation
- Fix the offending field value client-side to conform to its declared type
- Check that the UDT field type in the schema matches what the client sends
Defensive patterns
Strategy: validation
When it happens
Trigger: Thrown at src/java/org/apache/cassandra/serializers/UserTypeSerializer.java:68 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/555b0f2e0a9a2af0.
Report an issue: GitHub.
Appendix: source
Thrown at src/java/org/apache/cassandra/serializers/UserTypeSerializer.java:68
int size = accessor.getInt(input, offset);
offset += TypeSizes.INT_SIZE;
// size < 0 means null value
if (size < 0)
continue;
if (accessor.sizeFromOffset(input, offset) < size)
throw new MarshalException(String.format("Not enough bytes to read %dth field %s", i, entry.getKey()));
V field = accessor.slice(input, offset, size);
try
{
offset += size;
entry.getValue().validate(field, accessor);
}
catch (MarshalException e)
{
throw new MarshalException(String.format("Failure validating the %dth field %s; %s", i, entry.getKey(), e.getMessage()), e);
}
}
// We're allowed to get less fields than declared, but not more
if (!accessor.isEmptyFromOffset(input, offset))
throw new MarshalException("Invalid remaining data after end of UDT value");
}
}
View on GitHub (pinned to 88fd0f6a0e)