dotnet/aspnetcore · error · UnsupportedOperationException

The message type %s is not supported yet.

Error message

The message type %s is not supported yet.

What it means

An UnsupportedOperationException thrown by ReceiveLoop when an incoming message has type STREAM_INVOCATION or CANCEL_INVOCATION. These are server->client message types that the Java SignalR client does not implement (the client initiates streams via stream(), it does not receive stream-invocation requests from the server). The protocol parses the type and explicitly rejects it.

Source

Thrown at src/SignalR/clients/java/signalr/core/src/main/java/com/microsoft/signalr/HubConnection.java:527

                        continue;
                    }
                    irq.complete(completionMessage);
                    break;
                case STREAM_ITEM:
                    StreamItem streamItem = (StreamItem)message;
                    InvocationRequest streamInvocationRequest = connectionState.getInvocation(streamItem.getInvocationId());
                    if (streamInvocationRequest == null) {
                        logger.warn("Dropped unsolicited Completion message for invocation '{}'.", streamItem.getInvocationId());
                        continue;
                    }

                    streamInvocationRequest.addItem(streamItem);
                    break;
                case STREAM_INVOCATION:
                case CANCEL_INVOCATION:
                    logger.error("This client does not support {} messages.", message.getMessageType());

                    throw new UnsupportedOperationException(String.format("The message type %s is not supported yet.", message.getMessageType()));
            }
        }
    }

    /**
     * Stops a connection to the server.
     *
     * @return A Completable that completes when the connection has been stopped.
     */
    public Completable stop() {
        return stop(null);
    }

    private void stopConnection(String errorMessage) {
        RuntimeException exception = null;
        this.state.lock();
        try {
            ConnectionState connectionState = this.state.getConnectionStateUnsynchronized(true);

View on GitHub (pinned to 294cab2f9b)

Solutions

  1. Avoid server-side designs that invoke client streaming methods on the Java client; the Java client only supports client->server streaming via stream().
  2. Update to a newer client version that may support these message types, if available.
  3. If the server is yours, change it so it does not send STREAM_INVOCATION/CANCEL_INVOCATION to Java clients.

Example fix

// before: server-side hub calls a streaming method on the Java client
// (server) await Clients.Caller.SendAsync("StreamToMe", ...); // triggers STREAM_INVOCATION on client

// after: server sends discrete invocations the Java client can handle with .on(...)
// (server) await Clients.Caller.SendAsync("Item", payload);
// (client) connection.on("Item", (Item p) -> { ... }, Item.class);
Defensive patterns

Strategy: type-guard

Validate before calling

// There is no runtime pre-check; the fix is architectural: do not let the server
// invoke client streaming methods on the Java client. Validate your server-side hub
// design doesn't call stream-invocation toward Java clients.

Type guard

// The Java client only supports client->server streaming via stream().
// Server->client streaming (STREAM_INVOCATION) is unsupported and cannot be guarded at runtime.
boolean clientSupportsServerStreamInvocation = false;

Try / catch

// ReceiveLoop throws UnsupportedOperationException which propagates as a connection error.
// Subscribe to start()/onClosed to detect it, but the real fix is server-side.
connection.onClosed(ex -> {
    if (ex != null && ex.getMessage().contains("not supported yet")) {
        logger.error("Server sent an unsupported message type; redesign server-side streaming");
    }
});

Prevention

When it happens

Trigger: The server sends a STREAM_INVOCATION message (asking the client to start streaming results to the server) or a CANCEL_INVOCATION message. The client parses it in parseMessages and, in ReceiveLoop's switch (line 523-527), throws because handling is not implemented. Also thrown inside GsonHubProtocol.parseMessages at line 204 for the same types during parsing.

Common situations: A server-side hub invokes a client-side streaming method (server-to-client stream invocation), which the Java client cannot fulfill. A protocol or version mismatch where the server sends a message type the client doesn't expect. Misuse of the protocol where the server treats the client as a stream source.

Related errors


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