Matthew opened SPR-16109 and commented

The issue is:

A WebSocket request-response pattern using @SubscribeMapping does not currently work because of a null check.

The null check in question is from the handleReturnValue method in SubscriptionMethodReturnValueHandler:

if (subscriptionId == null) {
    throw new IllegalStateException("No simpSubscriptionId in " + message +
            " returned by: " + returnType.getMethod());
}

The steps to reproduce are:

Annotate a @Controller method with @SubscribeMapping in an application using Spring Boot's @EnableWebSocketMessageBroker, with a simple message broker configured.

Something like the following should reproduce the bug:

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketSupport extends AbstractWebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/endpoint")
                .setAllowedOrigins("*")
                .withSockJS()
        ;
    }
    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        config
                .setApplicationDestinationPrefixes("/app")
                .enableSimpleBroker("/topic", "/queue")
        ;
    }

    @Controller
    public class SocketMessageController {

        @SubscribeMapping("/ping")
        public SocketMessage handle(SocketMessage socketMessage) {
            return Service.command(socketMessage);
        }
    }
}

(According to the docs, the @SubscribeMapping should cause the return value to be sent back to the calling client.)

Then, call the endpoint using STOMP over WebSockets.

What happens is:

When the SubscriptionMethodReturnValueHandler is called, the null check for the simpSubscriptionId header prevents sending the response message back to the client.

A workaround is:

Add an identically named class SubscriptionMethodReturnValueHandler in an identically named package org.springframework.messaging.simp.annotation.support which does not perform this null check.
The socket message responses are sent to the calling client, (and only the calling client.)

Affects: 5.0.1

Issue Links:

• Introduce null-safety of Spring Framework API [SPR-15540] #20099 Introduce null-safety of Spring Framework API

Referenced from: commits 64bc9b4