Today’s the day I'm going to make another attempt ...

# apollo-kotlin

[Neal Sanche]

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]

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]

What context are you running your iOS code in?

[rocketraman]

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]

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]

Current exception is:

Uncaught Kotlin exception: kotlin.native.concurrent.FreezingException: freezing of Continuation @ $onUnsubscribed$<anonymous>_6COROUTINE$16 has failed, first blocker is ArrayChannel@147048{ReceiveQueued}(buffer:capacity=64,size=0)

[Neal Sanche]

Trying to figure out which line crashes in

private suspend fun onUnsubscribed() {
      mutex.withLock {
        if (--activeSubscriptionCount == 0 && idleTimeoutMs > 0) {
          /*
          idleTimeoutJob?.cancel()
          connectionKeepAliveTimeoutJob?.cancel()

          idleTimeoutJob = coroutineScope.launch {
            delay(idleTimeoutMs)
            close()
          }

           */
        }
      }
    }

[Neal Sanche]

With all of those commented, the iOS app works.

[Neal Sanche]

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]

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]

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.

Untitled

[Neal Sanche]

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]

kfun:com.apollographql.apollo.network.ws.ApolloWebSocketNetworkTransport.$openServerConnectionCOROUTINE$22.invokeSuspend#internal + 1269

[Neal Sanche]

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]

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<GraphQLWebsocketConnection> {
    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]

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]

Emit Result?

[Neal Sanche]

Sorry Raman, are you saying modify openServerConnection to return a Result<GraphQLWebsocketConnection> instead? That way the error can be contained?

[rocketraman]

I guess Flow<Result<GraphQLWebsocketConnection>>, yeah

[Neal Sanche]

So, the above might become:

private fun getServerConnection(dispatcherContext: ApolloCoroutineDispatcherContext): Flow<Result<GraphQLWebsocketConnection?>> {
    return flow {
      emit(kotlin.runCatching {
        mutex.withLock {
          if (graphQLWebsocketConnection?.isClosedForReceive() != false) {
            graphQLWebsocketConnection = openServerConnection(dispatcherContext)
          }
          graphQLWebsocketConnection
        }
      })
    }
  }

[Neal Sanche]

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]

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

[Neal Sanche]

Doesn't runCatching do that?

[rocketraman]

Yeah you could just throw with an elvis operator.

[Neal Sanche]

Okay, like this then?

Untitled.kt

[Neal Sanche]

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

[Neal Sanche]

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

[Neal Sanche]

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]

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]

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.

Untitled.kt