Seeing a crash in Atomic.swift L23

[tahirmt]

Summary

We just added Apollo 1.2.1 to our project and while I was looking through the crashes, I noticed this new one originating from Apollo.

Crashed: com.apple.NSURLSession-delegate
SIGSEGV 0x0000000000000010

Crashed: com.apple.NSURLSession-delegate
0  Apollo                         0x3eadc InterceptorRequestChain.proceedAsync<A>(request:response:completion:interceptor:) + 23 (Atomic.swift:23)
1  Apollo                         0x9698 ApolloInterceptorReentrantWrapper.proceedAsync<A>(request:response:completion:) + 38 (ApolloInterceptorReentrantWrapper.swift:38)
2  GraphQL                        0x12770 closure #1 in GeneralNetworkFetchInterceptor.interceptAsync<A>(chain:request:response:completion:) + 71 (GeneralNetworkFetchInterceptor.swift:71)
3  GraphQL                        0x12aa8 partial apply for closure #1 in GeneralNetworkFetchInterceptor.interceptAsync<A>(chain:request:response:completion:) + 44 (<compiler-generated>:44)
4  Apollo                         0x6b100 specialized URLSessionClient.urlSession(_:task:didCompleteWithError:) + 221 (URLSessionClient.swift:221)
5  Apollo                         0x6a0d8 @objc URLSessionClient.urlSession(_:task:didCompleteWithError:) + 104 (<compiler-generated>:104)
6  CFNetwork                      0x19bec CFURLRequestCopyHTTPRequestMethod + 2272
7  libdispatch.dylib              0x2320 _dispatch_call_block_and_release + 32
8  libdispatch.dylib              0x3eac _dispatch_client_callout + 20
9  libdispatch.dylib              0xb534 _dispatch_lane_serial_drain + 668
10 libdispatch.dylib              0xc0d8 _dispatch_lane_invoke + 436
11 libdispatch.dylib              0x16cdc _dispatch_workloop_worker_thread + 648
12 libsystem_pthread.dylib        0xddc _pthread_wqthread + 288
13 libsystem_pthread.dylib        0xb7c start_wqthread + 8

I worry it might become a big issue once this version hits production.

Version

1.2.1

Steps to reproduce the behavior

I don't have steps to reproduce at the moment but judging by the stack trace it looks like it happened after web socket was reconnected upon returning to foreground. We resubscribe to all the subscriptions the user had before backgrounding the app and also fetch (query) the current page the user is on when this happens. All at the same time.

Logs

No response

Anything else?

No response

[calvincestari]

This looks like a duplicate of #3057. It was fixed in #3070 and is available in 1.3.0 which was just released today. Note that it's a minor breaking change though; the migration guide has all the details.

[tahirmt]

Thanks @calvincestari I was looking in the open issues and couldn't find anything. Didn't realize a new release was out.

[tahirmt]

I didn't want to make a new issue for this question but is there a reason id is a get set property in the protocol instead of just get?
https://github.com/apollographql/apollo-ios/blob/0531744fc99336e4fee64642bf652237de8aa2a6/Sources/Apollo/ApolloInterceptor.swift#LL13C9-L13C9

[calvincestari]

I was looking at that earlier actually. I think the first version I had the request chain setting the value but that's not where it ended up; it should just be var id: String { get } instead.