bug: Query validation errors result in NullPointerException when using subscriptions

[ciprian197]

Expected behavior

When execution result has data as null but the errors field populated, I would expect the errors to be propagated instead of a NullPointerException, in the case of subscriptions.

Actual behavior

Sending an invalid query in a subscription results in a NPE in the handleSubscription method due to the ExecutionResult.data being null. private final void handleSubscription(final String id, QueryPayload payload, final WebSocketSession session) { ExecutionResult var10000 = this.dgsQueryExecutor.execute(payload.getQuery(), payload.getVariables()); Intrinsics.checkNotNullExpressionValue(var10000, "dgsQueryExecutor.execute…query, payload.variables)"); ExecutionResult executionResult = var10000; Object var6 = executionResult.getData(); Intrinsics.checkNotNullExpressionValue(var6, "executionResult.getData()");...

Logs: `21-07-09 08:20:25.448 WARN [nio-8080-exec-4] notprivacysafe.graphql.GraphQL : Query failed to validate : 'subscription schematicState { schematicStateChanged(filter: {pageIds: [23016]}) { id resourceIds resourceType stateType stateValue } }

' 21-07-09 08:20:25.450 ERROR [nio-8080-exec-4] raphQLExceptionWebSocketHandlerDecorator : Closing session due to exception for StandardWebSocketSession[id=2e942baf-9b94-d2f4-4151-0728a085529e, uri=wss://feature10.avelon/subscriptions]

java.lang.NullPointerException: executionResult.getData() must not be null at com.netflix.graphql.dgs.subscriptions.websockets.DgsWebSocketHandler.handleSubscription(DgsWebSocketHandler.kt:94) ~[graphql-dgs-subscriptions-websockets-4.3.1.jar!/:4.3.1] at com.netflix.graphql.dgs.subscriptions.websockets.DgsWebSocketHandler.handleTextMessage(DgsWebSocketHandler.kt:70) ~[graphql-dgs-subscriptions-websockets-4.3.1.jar!/:4.3.1] at ch.avelon.alcedo.config.subscription.GraphQLWebSocketHandler.handleTextMessage(GraphQLWebSocketHandler.java:52) ~[classes!/:na] at org.springframework.web.socket.handler.AbstractWebSocketHandler.handleMessage(AbstractWebSocketHandler.java:43) ~[spring-websocket-5.2.4.RELEASE.jar!/:5.2.4.RELEASE] at ch.avelon.alcedo.config.subscription.CustomGraphQLExceptionWebSocketHandlerDecorator.handleMessage(CustomGraphQLExceptionWebSocketHandlerDecorator.java:76) ~[classes!/:na] at org.springframework.web.socket.handler.WebSocketHandlerDecorator.handleMessage(WebSocketHandlerDecorator.java:75) ~[spring-websocket-5.2.4.RELEASE.jar!/:5.2.4.RELEASE] at org.springframework.web.socket.handler.LoggingWebSocketHandlerDecorator.handleMessage(LoggingWebSocketHandlerDecorator.java:56) ~[spring-websocket-5.2.4.RELEASE.jar!/:5.2.4.RELEASE] at org.springframework.web.socket.handler.ExceptionWebSocketHandlerDecorator.handleMessage(ExceptionWebSocketHandlerDecorator.java:58) ~[spring-websocket-5.2.4.RELEASE.jar!/:5.2.4.RELEASE] at org.springframework.web.socket.adapter.standard.StandardWebSocketHandlerAdapter.handleTextMessage(StandardWebSocketHandlerAdapter.java:114) ~[spring-websocket-5.2.4.RELEASE.jar!/:5.2.4.RELEASE] at org.springframework.web.socket.adapter.standard.StandardWebSocketHandlerAdapter.access$000(StandardWebSocketHandlerAdapter.java:43) ~[spring-websocket-5.2.4.RELEASE.jar!/:5.2.4.RELEASE] at org.springframework.web.socket.adapter.standard.StandardWebSocketHandlerAdapter$3.onMessage(StandardWebSocketHandlerAdapter.java:85) ~[spring-websocket-5.2.4.RELEASE.jar!/:5.2.4.RELEASE] at org.springframework.web.socket.adapter.standard.StandardWebSocketHandlerAdapter$3.onMessage(StandardWebSocketHandlerAdapter.java:82) ~[spring-websocket-5.2.4.RELEASE.jar!/:5.2.4.RELEASE] at org.apache.tomcat.websocket.WsFrameBase.sendMessageText(WsFrameBase.java:395) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.tomcat.websocket.server.WsFrameServer.sendMessageText(WsFrameServer.java:119) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.tomcat.websocket.WsFrameBase.processDataText(WsFrameBase.java:495) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:294) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:133) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:82) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.tomcat.websocket.server.WsFrameServer.doOnDataAvailable(WsFrameServer.java:171) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.tomcat.websocket.server.WsFrameServer.notifyDataAvailable(WsFrameServer.java:151) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:148) ~[tomcat-embed-websocket-9.0.31.jar!/:9.0.31] at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1639) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:na] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:na] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31] at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]`

Steps to reproduce

Create a subscription endpoint using DGS framework. Instead of sending the right query twist it a little to result in a query validation issue (ex: misspell one of the expected fields).

Schema example: `type Subscription {

schematicStateChanged(filter: PageStatePropagationFilter) : SchematicState

}

type SchematicState {

id: Int!
resourceId: Int!
resourceType: ResourceType!
stateValue: String!
stateType: SchematicStateType!

}`

Query example: subscription schematicState { schematicStateChanged(filter: {pageIds: [23016]}) { id resourceIdsWhichIsWrong resourceType stateType stateValue } }

If needed I can set up a repository with the code to replicate the issue.

[svolpe43]

Is this a known issue? I am currently hitting this as well. Can't seem to handle exceptions while using subscriptions without the exact NPE error posted above.