apache/hadoop · error · IOException
Encoded type {} converted to valid component type {} but no
Error message
Encoded type {} converted to valid component type {} but no encoding is implemented for this type. What it means
The tail else of readFields()'s dispatch chain: the component type name resolved to a class in PRIMITIVE_NAMES (so getPrimitiveClass returned non-null) but none of the eight read branches matched. Since PRIMITIVE_NAMES contains exactly the eight handled primitives, this is a defensive, effectively unreachable internal-consistency check — it can only fire if a fork adds a name to the map without a corresponding readXxxArray branch, or state is mutated abnormally.
Source
Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/ArrayPrimitiveWritable.java:247
// do the inner loop. Walk the decision tree only once.
if (componentType == Boolean.TYPE) { // boolean
readBooleanArray(in);
} else if (componentType == Character.TYPE) { // char
readCharArray(in);
} else if (componentType == Byte.TYPE) { // byte
readByteArray(in);
} else if (componentType == Short.TYPE) { // short
readShortArray(in);
} else if (componentType == Integer.TYPE) { // int
readIntArray(in);
} else if (componentType == Long.TYPE) { // long
readLongArray(in);
} else if (componentType == Float.TYPE) { // float
readFloatArray(in);
} else if (componentType == Double.TYPE) { // double
readDoubleArray(in);
} else {
throw new IOException("Encoded type " + className
+ " converted to valid component type " + componentType.toString()
+ " but no encoding is implemented for this type.");
}
}
//For efficient implementation, there's no way around
//the following massive code duplication.
private void writeBooleanArray(DataOutput out) throws IOException {
boolean[] v = (boolean[]) value;
for (int i = 0; i < length; i++)
out.writeBoolean(v[i]);
}
private void writeCharArray(DataOutput out) throws IOException {
char[] v = (char[]) value;
for (int i = 0; i < length; i++)
out.writeChar(v[i]);View on GitHub (pinned to 2add963021)
Solutions
- If you maintain a fork that adds a primitive, add both the map entry and the matching readXxxArray branch.
- Otherwise, treat this as evidence of tampered internals or a classpath mix of Hadoop versions — align hadoop-common jars across the cluster.
Defensive patterns
Strategy: try-catch
Try / catch
try {
w.readFields(in);
} catch (IOException e) {
LOG.error("Read dispatch failed for " + w.getComponentType(), e);
throw e;
} Prevention
- In forks, keep PRIMITIVE_NAMES and the read/write dispatch chains in sync when adding types.
- Pin one hadoop-common version across the classpath to avoid mixed implementations.
When it happens
Trigger: A modified/forked ArrayPrimitiveWritable where PRIMITIVE_NAMES and the read dispatch chain are out of sync; reflection-assigned componentType. Not reachable in stock Hadoop.
Common situations: Vendored or patched hadoop-common where someone extended the supported primitive set incompletely.
Related errors
- Component type {} is set as the output type, but no encoding
- No URI in deserialized Path
- encoded array component type {} is not a candidate primitive
- encoded array length is negative {}
- Cannot initialize the class: {clazz}
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/d51a7387ab19076f.
Report an issue: GitHub.