WebSocket keepalive PING not emitted for all idle concurrent sessions

[KelltonTechSolutions]

I am seeing inconsistent server-side WebSocket keepalive behavior with Spring GraphQL over WebFlux.

The application is configured with:

spring.graphql.websocket.path=/graphql
spring.graphql.websocket.keep-alive=15s
spring.netty.idle-timeout=0
In a scenario with two concurrent GraphQL WebSocket clients using the graphql-transport-ws protocol, one connection receives periodic server PING frames while another concurrently active connection does not.

I reviewed the keepalive support added in commit 80ef960 and expected each idle WebSocket connection to receive server PING frames independently.

This is on my local environment, when i deploy the solution to POD. SLB, closes the connection after XX duration for session B.

Question

Is this behavior expected because Spring GraphQL suppresses keepalive when a session has had recent encoded output, or should each concurrently idle WebSocket session receive its own PING frames independently?

[KelltonTechSolutions]

Please prioritize!

[rstoyanchev]

No it is not expected. Each session should have its own pings.

We prioritize issues that come with isolated samples that help us to spend less time reproducing the issue.

[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.

[KelltonTechSolutions]

I am working on building asset you requested. I will share it by EOD tomorrow 05/12

[KelltonTechSolutions]

I am able to reproduce the issue on my local also.. unfortunately i am not able to build a patch yet.

From reviewing the Spring GraphQL GraphQlWebSocketHandler implementations for both WebFlux and WebMVC, we found a difference in how keepalive appears to be managed, and this seems relevant to the issue we are observing in our application, which uses WebFlux.

ackFlux.mergeWith( Flux.interval(keepAliveDuration, keepAliveDuration) .filter(tick -> !codecDelegate.checkMessagesEncodedAndClear()) .map(tick -> codecDelegate.encode(session, GraphQlWebSocketMessage.ping(null))) );

In the WebFlux GraphQlWebSocketHandler, keepalive support is implemented by starting a periodic interval after connection_init and sending a GraphQL ping only when no other message was recently encoded. However, the logic appears to rely on a WebSocketCodecDelegate held as a handler-level field, and that delegate maintains a single mutable messagesEncoded flag. Since GraphQlWebSocketHandler is effectively a shared handler, this suggests the “recent outbound activity” signal may be shared across multiple concurrent WebSocket sessions rather than tracked independently per session.

By contrast, the WebMVC GraphQlWebSocketHandler maintains explicit per-session state through a session map and session-specific state holder objects, including keepalive-related state. That design appears session-scoped, whereas the WebFlux implementation appears to use handler-scoped outbound activity tracking for keepalive suppression.

We are using Spring GraphQL over WebFlux, and in our environment we are observing that with multiple concurrent WebSocket sessions, only a subset of sessions continue to receive GraphQL keepalive ping frames, while other sessions stop receiving keepalives even though they can still receive normal subscription event messages. In our deployed environment, those sessions that stop receiving keepalive are later closed by the load balancer after the idle timeout window.

Based on this review, our concern is that in the WebFlux GraphQlWebSocketHandler, keepalive suppression may not be isolated per WebSocket session. If outbound traffic on one session updates a shared “message encoded” flag, then keepalive for another otherwise idle session may be incorrectly skipped. This would align with the behavior we are seeing in production on WebFlux and would also explain why the same pattern would not be expected from the WebMVC implementation, where the state handling appears per session.