Websocket errors are not handled

[Sam-Kruglov]

spring-graphql/spring-graphql/src/main/java/org/springframework/graphql/server/webmvc/GraphQlWebSocketHandler.java

Lines 325 to 335 in 29ee6aa

	if (response.getData() instanceof Publisher) {
	// Subscription
	responseFlux = Flux.from((Publisher<ExecutionResult>) response.getData())
	.map(ExecutionResult::toSpecification)
	.doOnSubscribe((subscription) -> {
	Subscription prev = getSessionInfo(session).getSubscriptions().putIfAbsent(id, subscription);
	if (prev != null) {
	throw new SubscriptionExistsException();
	}
	});
	}

ExecutionResult#getErrors can contain errors but it's never checked. My annotated handlers are not invoked.

I work around this by directly reading the data as Flux:

    @Bean
    fun requestErrorLogger() = WebGraphQlInterceptor { request: WebGraphQlRequest, chain: WebGraphQlInterceptor.Chain
        ->
        chain.next(request).map { response ->
            if (response.getData<Any?>() is Publisher<*>) {
                return@map response.transform {
                    it.data(
                        Flux.from(response.getData<Publisher<ExecutionResult>>()!!)
                            .doOnNext { result ->
                                result.errors.forEach { error ->
                                    log.error(...)
                                }
                            }
                    )
                }
            }
            ...

I assume basically any error that can happen will be missed but if you want a specific case, I had this graphql.TypeMismatchError.

That error came from graphq-java when some resolver failed and the execution result/context contained errors here: https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/execution/SubscriptionExecutionStrategy.java#L165

[rstoyanchev]

GraphQlWebSocketHandler is the transport layer. It is too low level to know about controllers for a start. Secondly, the very end of the processing chain can only make decisions about escaped errors like a Publisher error signal not already handled.

The ExecutionResult is prepared at some point earlier in the processing chain, usually as a result of exception handling. It is the response (or event in subscriptions) and once prepared, it is just a matter of transporting it to the client. It is not anything for the transport layer to concern itself with. It is a normal response that's part of the GraphQL protocol.

We do have exception handling at the point of controller method invocation which routes publisher errors to annotated exception handler methods. We also have subscription exception resolvers. I'm mentioning this but can't advise without details.

In short this is more nuanced. It will help to see a concrete example to understand where how the error occurs, the controller methods involved, and so on.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.