dotnet/aspnetcore · error · RuntimeException

MessagePack message was length %d but claimed to be length %

Error message

MessagePack message was length %d but claimed to be length %d.

What it means

After reading the varint length prefix in parseMessages, the protocol checks that the remaining bytes in the buffer are at least as long as the declared length. If the declared length exceeds what is actually present, the message is corrupt or truncated and parsing aborts immediately.

Source

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

            return null;
        }

         // MessagePack library can't handle read-only ByteBuffer - copy into an array-backed ByteBuffer if this is the case
        if (payload.isReadOnly()) {
            byte[] payloadBytes = new byte[payload.remaining()];
            payload.get(payloadBytes, 0, payloadBytes.length);
            payload = ByteBuffer.wrap(payloadBytes);
        }

        List<HubMessage> hubMessages = new ArrayList<>();

        while (payload.hasRemaining()) {
            int length;
            try {
                length = Utils.readLengthHeader(payload);
                // Throw if remaining buffer is shorter than length header
                if (payload.remaining() < length) {
                    throw new RuntimeException(String.format("MessagePack message was length %d but claimed to be length %d.", payload.remaining(), length));
                }
            } catch (IOException ex) {
                throw new RuntimeException("Error reading length header.", ex);
            }
            // Instantiate MessageUnpacker
            try(MessageUnpacker unpacker = MessagePack.newDefaultUnpacker(payload)) {

                int itemCount = unpacker.unpackArrayHeader();
                HubMessageType messageType = HubMessageType.values()[unpacker.unpackInt() - 1];

                switch (messageType) {
                    case INVOCATION:
                        hubMessages.add(createInvocationMessage(unpacker, binder, itemCount, payload));
                        break;
                    case STREAM_ITEM:
                        hubMessages.add(createStreamItemMessage(unpacker, binder, payload));
                        break;
                    case COMPLETION:

View on GitHub (pinned to 294cab2f9b)

Solutions

1. Ensure the transport delivers complete, unmodified binary frames.
2. Align client and server SignalR MessagePack protocol versions.
3. Inspect for any proxy that buffers, re-encodes, or truncates the stream.

// Java
hubConnection.start().subscribe(ok -> {}, err -> {
    if (err.getMessage() != null && err.getMessage().contains("claimed to be length")) {
        // suspect truncation/proxy/version mismatch
    }
});

When it happens

Trigger: Truncated MessagePack payload delivered by the transport; framing corruption; a proxy truncating the binary stream; partial read reassembled incorrectly.

Common situations: Reverse proxy/load balancer altering or truncating binary payloads; mismatched SignalR/MessagePack protocol versions; network interruption mid-frame.

Related errors

• Cannot read message size.
• Messages bigger than 2GB are not supported.
• Error reading length header.
• Error reading MessagePack data.
• Unexpected message type: %d

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