dotnet/aspnetcore · error · RuntimeException

Unexpected message type: %d

Error message

Unexpected message type: %d

What it means

writeMessage switches on HubMessageType when serializing outbound and throws for an unrecognized type value. This indicates an internal/library inconsistency — a HubMessage whose getType() returns a value outside INVOCATION/STREAM_ITEM/COMPLETION/STREAM_INVOCATION/CANCEL_INVOCATION/PING/CLOSE.

Source

Thrown at src/SignalR/clients/java/signalr/messagepack/src/main/java/com/microsoft/signalr/messagepack/MessagePackHubProtocol.java:172

                    message = writeStreamItemMessage((StreamItem) hubMessage);
                    break;
                case COMPLETION:
                    message = writeCompletionMessage((CompletionMessage) hubMessage);
                    break;
                case STREAM_INVOCATION:
                    message = writeStreamInvocationMessage((StreamInvocationMessage) hubMessage);
                    break;
                case CANCEL_INVOCATION:
                    message = writeCancelInvocationMessage((CancelInvocationMessage) hubMessage);
                    break;
                case PING:
                    message = writePingMessage((PingMessage) hubMessage);
                    break;
                case CLOSE:
                    message = writeCloseMessage((CloseMessage) hubMessage);
                    break;
                default:
                    throw new RuntimeException(String.format("Unexpected message type: %d", messageType.value));
            }
            int length = message.length;
            List<Byte> header = Utils.getLengthHeader(length);
            byte[] messageWithHeader = new byte[header.size() + length];
            int headerSize = header.size();

            // Write the length header, then all of the bytes of the original message
            for (int i = 0; i < headerSize; i++) {
                messageWithHeader[i] = header.get(i);
            }
            for (int i = 0; i < length; i++) {
                messageWithHeader[i + headerSize] = message[i];
            }

            return ByteBuffer.wrap(messageWithHeader);
        } catch (MessagePackException | IOException ex) {
            throw new RuntimeException("Error writing MessagePack data.", ex);
        }

View on GitHub (pinned to 294cab2f9b)

Solutions

  1. Only send standard hub message instances produced by the SDK (invoke/send/stream).
  2. Never subclass HubMessage to send custom types.
  3. If it recurs with stock usage, report it with a repro against the official library.
Defensive patterns

Strategy: try-catch

Try / catch

// Java
try {
    hubConnection.send("Method").blockingAwait();
} catch (RuntimeException ex) {
    if (ex.getMessage() != null && ex.getMessage().contains("Unexpected message type")) {
    }
}

Prevention

When it happens

Trigger: Constructing or sending a HubMessage whose type is outside the known enum; a custom HubMessage subclass; an enum value added without the writer being updated.

Common situations: Custom HubMessage subclass passed to send; library internal bug; mixing incompatible library builds.

Related errors


AI-assisted analysis of dotnet/aspnetcore@294cab2f9b (2026-08-06). Data as JSON: /api/errors/a1700f576ae85432. Report an issue: GitHub.