Today s the day I m going to make another attempt to get a G

Question

Today s the day I m going to make another attempt to get a GraphQL subscription working in iOS Wish me luck KMM memory model woes

Neal Sanche · Answer

So far more of the same ```Uncaught Kotlin exception kotlin native concurrent InvalidMutabilityException mutation attempt of frozen com apollographql apollo network ws ApolloWebSocketNetworkTransport 6f8e68``` I am going to try to refactor things so that instead of using a kotlin `object` as the source of the ApolloClient instances I will use `koin` instead Not sure if that s going to change the outcome here but it s worth a try I suppose

rocketraman · Answer

What context are you running your iOS code in

rocketraman · Answer

The approach I took was to run all my graphql api calls in the `MainScope ` `CoroutineScope` That worked perfectly on both Android and iOS

Neal Sanche · Answer

I m generally not changing the coroutine scope it is using multithreaded coroutines and the Dispatcher Main for much of this Regular GraphQL queries were working just fine But a subscription test I m making wasn t working at all I have just finished implementing Koin to build up my dependencies in a more controlled way and data came across in the Flow However there is still a crash that I m looking into

Neal Sanche · Answer

Current exception is ```Uncaught Kotlin exception kotlin native concurrent FreezingException freezing of Continuation $onUnsubscribed$ lt anonymous gt 6COROUTINE$16 has failed first blocker is ArrayChannel 147048 ReceiveQueued buffer capacity=64 size=0 ```

Neal Sanche · Answer

Trying to figure out which line crashes in ``` private suspend fun onUnsubscribed mutex withLock if activeSubscriptionCount == 0 amp amp idleTimeoutMs gt 0 idleTimeoutJob cancel connectionKeepAliveTimeoutJob cancel idleTimeoutJob = coroutineScope launch delay idleTimeoutMs close ```

Neal Sanche · Answer

With all of those commented the iOS app works

Neal Sanche · Answer

So after spending a bit of time with this block of code above in `ApolloWebSocketNetworkTransport kt` I find that the iOS app crashes if there is any code in this lambda ```idleTimeoutJob = coroutineScope launch delay idleTimeoutMs close ``` If I leave the `delay` or the `close ` in there we have the same crash as above a FreezingException There is only two places in this code where coroutines are launched I m going to do some experimentation

Neal Sanche · Answer

Reading through the code to find the source of the `coroutineScope` being used here I found the execute method can take a dispatcher and I was able to get this subscription working using that Testing some more to ensure it wasn t a fluke

Neal Sanche · Answer

Definitely not a fluke it seems So what have I done I used Koin to inject ApolloClient to the rest of the code I am running The subscription itself is probably not important pretty standard I made The addition of the `executionContext` parameter to the `execute` method here is what stopped the crashes that I was seeing I absolutely need the `flowOn` as well

Neal Sanche · Answer

Found another crash in here however if I take my server down and try to connect the iOS app crashes with ```Uncaught Kotlin exception com apollographql apollo ApolloWebSocketException Failed to establish GraphQL websocket connection with the server timeout ```

Neal Sanche · Answer

```kfun com apollographql apollo network ws ApolloWebSocketNetworkTransport $openServerConnectionCOROUTINE$22 invokeSuspend internal + 1269```

Neal Sanche · Answer

Not sure where this exception is going because I don t seem to be able to catch it the same way I had for other classes

Neal Sanche · Answer

This morning I m trying to figure out why the connection timeout exceptions aren t being handled and bubbled up for the websocket connections I ve discovered the root cause of this in the `getServerConnection` method of ApolloWebSocketNetworkTransport which creates a flow that internally calls `openServerConnection` That method can throw ApolloWebSocketException Those exceptions crash the app unless they are caught Naively I added the following code to suppress them ``` private fun getServerConnection dispatcherContext ApolloCoroutineDispatcherContext Flow lt GraphQLWebsocketConnection gt return flow val connection = mutex withLock if graphQLWebsocketConnection isClosedForReceive = false graphQLWebsocketConnection = openServerConnection dispatcherContext graphQLWebsocketConnection emit connection catch emit null filterNotNull ``` the `catch` at the bottom emits null which is immediately filtered But this ultimately fixes the crash I m currently seeing

Neal Sanche · Answer

Clearly it d be better to pass that exception up and handle it as an error I ll see if I can figure out a nice way to have this happen the `flow ` builder doesn t seem to have an emit error functionality though

rocketraman · Answer

Emit `Result`

Neal Sanche · Answer

Sorry Raman are you saying modify openServerConnection to return a Result lt GraphQLWebsocketConnection gt instead That way the error can be contained

rocketraman · Answer

I guess `Flow lt Result lt GraphQLWebsocketConnection gt gt ` yeah

Neal Sanche · Answer

So the above might become ``` private fun getServerConnection dispatcherContext ApolloCoroutineDispatcherContext Flow lt Result lt GraphQLWebsocketConnection gt gt return flow emit kotlin runCatching mutex withLock if graphQLWebsocketConnection isClosedForReceive = false graphQLWebsocketConnection = openServerConnection dispatcherContext graphQLWebsocketConnection ```

Neal Sanche · Answer

But that leads to problems upstream of this need to rewrite how this is consumed Not sure why I have to handle nullable GraphQLWebsocketConnection here

rocketraman · Answer

Make it non nullable and emit an error Result instead if it is null

Neal Sanche · Answer

Doesn t runCatching do that

rocketraman · Answer

Yeah you could just throw with an elvis operator

Neal Sanche · Answer

Okay like this then

Neal Sanche · Answer

So the code that was consuming the serverConnection needs to be changed to handle a Result now Working through that

Neal Sanche · Answer

Not much luck so far Getting hung up on exactly what to do with the error part of the Result

Neal Sanche · Answer

Okay I was able to get this working in a way I m still not sure why the exceptions that are getting thrown don t get passed up to iOS the way I expect they should Using runCatching and then if there is an error sending that error to the flow that execute produces in the errors array of the response works But in this case the error is a timeout while trying to connect to the server not an actual graphql error It does work though

Neal Sanche · Answer

Okay I ve rolled out the changes I made and have figured out how to do the error handling in a better way The Apollo code as written works and I ve figured out workarounds for getting it running on iOS

Neal Sanche · Answer

I was able to get this sort of code to work on iOS to consume a subscription The difference here being the use of the `catch` operator if errors in connection need to be sent along with the rest of the flow If it doesn t matter the flow will just finish if the server can t be contacted so nothing needs to be emitted