dotnet/aspnetcore · error · RuntimeException
Extension types are not supported
Error message
Extension types are not supported
What it means
The MessagePack reader explicitly refuses EXTENSION value types — only nil/boolean/integer/float/string/binary/array/map are handled. Any extension-type byte encountered in a value triggers this throw. MessagePack extension types are used for things like timestamps and custom user types.
Source
Thrown at src/SignalR/clients/java/signalr/messagepack/src/main/java/com/microsoft/signalr/messagepack/MessagePackHubProtocol.java:633
if (itemType == null) {
return null;
}
return objectMapper.readValue(payloadBytes, payload.position() + (int) readBytesStart, (int) (unpacker.getTotalReadBytes() - readBytesStart),
typeFactory.constructType(itemType));
} else {
// This is an inner call to readValue - we just need to read the right number of bytes
// We can return null, and the outermost call will know how many bytes to give to objectMapper.
return null;
}
case EXTENSION:
/*
ExtensionTypeHeader extension = unpacker.unpackExtensionTypeHeader();
byte[] extensionValue = new byte[extension.getLength()];
unpacker.readPayload(extensionValue);
//Convert this to an object?
item = extensionValue;
*/
throw new RuntimeException("Extension types are not supported");
default:
return null;
}
// If itemType was null, we were just in this method to advance the buffer. return null.
if (itemType == null) {
return null;
}
// If we get here, the item isn't a map or a collection/array, so we use the Class to cast it
if (itemClass.isPrimitive()) {
return Utils.toPrimitive(itemClass, item);
}
return itemClass.cast(item);
}
private void writeValue(Object o, MessagePacker packer) throws IOException {
packer.addPayload(objectMapper.writeValueAsBytes(o));
}
}View on GitHub (pinned to 294cab2f9b)
Solutions
- Encode timestamps/dates as ISO-8601 strings or epoch numbers instead of MessagePack ext.
- Configure the server's MessagePack options to not use extension types for dates.
- Avoid sending custom extension-typed values across the hub boundary.
Example fix
// before: server emits DateTime as msgpack timestamp ext // after: server sends DateTime as ISO-8601 string public record Dto(string timestampUtc);
Defensive patterns
Strategy: validation
Validate before calling
// C# server - serialize dates as strings, not msgpack ext public record Dto([property: JsonExtensionData] ... string timestampUtc);
Try / catch
// Java
hubConnection.start().subscribe(ok -> {}, err -> {
if (err.getMessage() != null && err.getMessage().contains("Extension types")) {
// server is emitting msgpack ext (likely timestamps); switch to string dates
}
}); Prevention
- Encode dates/times as ISO-8601 strings or epoch numbers rather than MessagePack ext.
- Configure the server MessagePack options to avoid extension types for dates.
- Do not use custom MessagePack encoders that emit ext codes.
When it happens
Trigger: A peer sends a MessagePack extension type (e.g. a timestamp ext) in a hub argument or value; a custom encoder uses extension types; jackson-datatype-jsr310 producing ext-encoded timestamps.
Common situations: Server serializing DateTime/OffsetDateTime as a MessagePack timestamp extension; custom MessagePack encoder on the server; sending types whose serializer emits ext codes.
Related errors
- Cannot read message size.
- Messages bigger than 2GB are not supported.
- Incomplete message.
- MessagePack message was length %d but claimed to be length %
- Error reading length header.
AI-assisted analysis of dotnet/aspnetcore@294cab2f9b (2026-08-06).
Data as JSON: /api/errors/94b47bd522963f98.
Report an issue: GitHub.