:wave: Quick question about multiplatform support...

# apollo-kotlin

[mateusz.kwiecinski]

👋 Quick question about multiplatform support. I have a conditionally-block-all-network-calls requirement, that is currently implemented by OkHttp's interceptor, which depending on some internal state either proceeds with the original request or cancels it preemptively. The OkHttp's based code is (simplifying):

override fun intercept(chain: Interceptor.Chain): Response {
    if (isAppBlocked()) {
        chain.call().cancel()
    }

    return chain.proceed(chain.request())
}

which results in the query/mutation being cancelled with the following exception 👇
Looking at the documentation, the multi-platform way is to use Apollo's HttpInterceptor, but it doesn't seem to have a capability to cancel an ongoing request. Does the apollo-kotlin client have an multiplatform-enabled API allowing such behavior somewhere? If not, would you be open to extend the API surface to cancel ongoing network requests?

[mateusz.kwiecinski]

I can also share alternative approaches I considered:
1. Returning an artificial error response from interceptor (something like https://stackoverflow.com/a/47442152/5310155), but it produces different result than I expect
2. Throwing exception within HttpInterceptor, but I wasn't sure if it cleans up all resources properly
3. Wrapping the whole ApolloClient in a custom class that drops queries eagerly, but Interceptors are much more preferred, since they covers scenarios like when refetching mechanism tries to reach the network

[bod]

1. Looks like a simple solution 💡 - what was the issues you got with it?

[mateusz.kwiecinski]

So my main concern was creating proper response, without breaking someone's assumptions on how things work. I mean, there are two aspects:
1. According to SO OkHttp had their own internal requirements for the response, which changed across versions. I'd be afraid the same could happen with Apollo.
2. I wasn't sure if it is legal to break the chain and not proceed with the request. I was afraid it'd break someone's assumption when interceptors are called (so things like error logs or analytics could break then)

[mbonnin]

You could implement your own HttpEngine that delegates to the default one (or throws). It's 100% safe to throw ApolloNetworkException from HttpEngine.execute , this is what's happening on I/O errors

[mbonnin]

I'm tempted to say the same is true about interceptors but I'm not 100% sure.

[mateusz.kwiecinski]

You could implement your own HttpEngine

interesting, thanks for the idea! I'll give it a try 👍