Max reconnectWhen on retries on Apollo subscription client


today I have a small question regarding the here described 11. Write your first subscription - Apollo GraphQL Docs retry mechanism.

1st of all, cool that this possibility exist. But in case the WebSocket connection is closed f.e. can we restrict the number of this retries somehow?

Or does this retry run in endless loop and retry over and over again?

F.e. with an ApolloInterceptor, like f.e. described here?

If I would apply this interceptor to a subscription apollo client, would that have some effect?

Thanks in regards for the help here :slightly_smiling_face:. It is always nice to have a place where to raise questions as apollo newbie :slightly_smiling_face:.


You could definitely have your custom logic in the lambda passed to retryWhen and return false if attempt is higher than a certain value for instance.

If you’d like to have a global WebSocket reconnection mechanism however, instead of an interceptor you can use the webSocketReconnectWhen method on your ApolloClient. It takes a lambda with which you can react to exceptions received in the course of the WebSocket connection, and return true (reconnect) or false (don’t reconnect).

(Note that it is deprecated because it will be replaced with the equivalent webSocketReopenWhen method in the next release).

Hi Benoit,

thank you for your answer :slightly_smiling_face:. Okay with a webSocketReconnectWhen I can also try reconnection in error case :+1:. My goal is that the retry mechanism is automatically stopped after x times of retry without success. And if possible avoid to have a custom logic inside the lambda for this :slightly_smiling_face:.

So adding an Apollo interceptor MaxRetryInterceptor (like described here would help for this?

My goal is that the retry mechanism is automatically stopped after x times of retry without success.

In fact that was the reason for having a new version of the method (webSocketReopenWhen): it takes the attempt number as a parameter :grin:. However this version is not released yet, so for now retryWhen is your best bet.
I would say having the logic in the lambda is a fine way to do this.

Regarding an interceptor: MaxRetryInterceptor you reference is on the iOS library and we don’t have the equivalent on Apollo Kotlin, but I think it should be possible to implement a reconnect policy mechanism via a custom ApolloInterceptor.


Hello Benoit,

thanks for clarification :slightly_smiling_face:. Okay in that case I think it is okay for me to wait until webSocketReopenWhen is available.

Thank you for the help here. My question is answered by this.

1 Like