Closed KhaledElsherbeny closed 2 weeks ago
Interesting! I don't think we've ever had anyone hit this assertion failure before! It's possible there is a race condition going on here, but I would need more information in order to determine what's going on here.
Are you using a custom InterceptorProvider
? I might need some more example code or a reproduction case to dig into this.
Thanks for your response @AnthonyMDev
We don't use any custom InterceptorProvider
func createApolloClient() -> ApolloClientProtocol {
let configuration = URLSessionConfiguration.default
configuration.httpAdditionalHeaders = headers
NetworkLogger.enableLogging(for: configuration)
let store = ApolloStore(cache: ApolloCacheContainer.shared.normalizedCache())
let client = URLSessionClient(sessionConfiguration: configuration)
let provider = DefaultInterceptorProvider(client: client, store: store)
let networkTransport = RequestChainNetworkTransport(interceptorProvider: provider, endpointURL: url)
let apolloClient = ApolloClient(networkTransport: networkTransport, store: store)
return ApolloClientProxy(apolloClient: apolloClient)
}
and our ApolloClientProxy class we added to perform some business needs but its simple
final class ApolloClientProxy: ApolloClientProtocol {
var apolloClient: ApolloClient
var store: ApolloStore
init(apolloClient: ApolloClient) {
self.apolloClient = apolloClient
store = apolloClient.store
}
}
please advise is there any idea to help ?
@KhaledElsherbeny is this a consistent crash? Is it reproducible?
The cause of the assertion is that the internal task (TaskData
) related to the URLSessionDataTask
cannot be found. We use the TaskData
instance to store the response, data and completion handlers for the request; I thought we should maybe send a request failure result instead of asserting but without TaskData
we don't have a completion block so an assertion might be the only thing we can do here otherwise it would just fail silently.
There are a number of ways the internal task data can be removed:
invalidate
which essentially kills the session client so this is a pretty severe action. The only place we call this method is when the DefaultInterceptorProvider
is released (deinit
) and that is further controllable through the shouldInvalidateClientOnDeinit
property.clear(task:)
which is called when a task is cancelled or completes. I don't believe we ever make the call to cancel a task.clearAllTasks
which is called by invalidate
or when 4 occurs.URLSession
being invalidated through the delegate call urlSession(_:didBecomeInvalidWithError:)
I recommend checking whether you call any of those methods in your own code. Also trying to nail down the circumstances of, and how reproducible, the error is would be helpful in tracking down the root cause.
@KhaledElsherbeny were you ever able to resolve this one? We're going to need some more information on this in order to determine if there is a bug in our code and how to resolve it.
We're closing this for now due to inactivity, but we will be happy to re-open if you respond with additional information.
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.
Summary
crash occurred randomly while starting calling query
Version
1.13.0
Steps to reproduce the behavior
crash occurred randomly while starting calling query
Logs
No response
Anything else?
No response