Main thread checks on iOS 15 - unexpected result

[lukeredpath]

Describe the bug
I'm currently doing some smoke testing of our app on iOS 15 using the latest Xcode beta (beta 5) in preparation for the forthcoming final release.

We're using TCA 0.27 and it looks like the recently added main thread checks aren't working as expected, I'm getting output like this:

Warning:

The store was interacted with on a thread that is different from the thread the store was created on:

"ViewStore.send([redacted action])" was called on the wrong thread. Make sure that "ViewStore.send" is always called on the initial thread.

  Initial thread: <NSThread: 0x600000162680>{number = 29, name = main}
  Current thread: <_NSMainThread: 0x6000001b40b0>{number = 1, name = main}

The "Store" class is not thread-safe, and so all interactions with an instance of "Store" (including all of its scopes and derived view stores) must be done on the same thread.
---

Caught debug breakpoint. Type "continue" ("c") to resume execution.

The weird thing here is I know that the first action sent to my store would have been on the main thread because we fire an action in application(_:didFinishLaunching) so I don't know how the initial thread is not the main thread (although strangely it has the name "main").

To Reproduce
If I can put together a reproducer I will uploaded it here.

Expected behavior
When the first action in the app is sent on the main thread, other actions sent from the main thread should not trigger this breakpoint.

Environment

• TCA 0..27
• Xcode 13b5
• iOS 15.

[mbrandonw]

Very interesting, thanks for the report!

The weird thing here is I know that the first action sent to my store would have been on the main thread because we fire an action in application(_:didFinishLaunching) so I don't know how the initial thread is not the main thread (although strangely it has the name "main").

The "Initial thread" referenced in that message refers to the thread where the root store was created on. Could you breakpoint where that happens and confirm its on the main thread? And that Thread.current is the main thread?

If it really is possible to have two different thread references that both represent the "main" thread then we may have to rethink some of this.

[lukeredpath]

Hmm, interesting. So our root store is created by a coordinator object that is initialised as a singleton, (e.g. static let liveCoordinator = Coordinator()) - the store is created in the Coordinator's init.

We first reference this live coordinator in the application(_:didFinishLaunching) method although due to the static I'm not 100% of the lifecycle.

IIRC, "thread 29" appeared to be owned by NSURLConnection - I don't know if that provides a clue. We do reference our app coordinator in application(_:handleEventsForBackgroundSession:completionHandler:) too but I'd be surprised if this method was even called in my very limited simulator smoke testing (I hadn't even backgrounded the app). Very odd that this thread had the name "main" though. I've always assumed the main thread is always Thread 1.

I will keep an eye on this and see if it happens again as we continue to test. I've only experienced it once so far. It doesn't help that we are still running a more than month old beta. 🤞🏻 for an updated Xcode this week.

[mbrandonw]

One thing you could try is to temporarily change the static let liveCoordinator to be a static var computed property so that you can get a breakpoint in there and confirm the thread.

[tgrapperon]

@lukeredpath Is the app using an "old" UIApplicationDelegate? Are you using some kind of logging/crash reporting framework? I've seen these things mess with NSObject.load() in the past, so I can imagine them creating additional threads and bootstrapping the store by mistake.

[lukeredpath]

@tgrapperon we've actually just converted our app over to the SwiftUI app lifecycle but we are still using @UIApplicationDelegateAdaptor and our old app delegate class.

We do have a few analytics/crash reporting tools too that could potentially be messing with this. I'll give Brandon's suggestion a try, but most of the time it seems to work OK. I might add a precondition check to our Coordinator.init method and guard that it is initialised on the main thread.

[stephencelis]

@lukeredpath Have you managed to find the root of the problem? Was the store somehow being initialized on a background thread? We'd love to know if this is an issue with our thread checking code or not 😄

[lukeredpath]

@stephencelis not yet - we'll be running our app on iOS 15 more extensively over the next week now the Xcode RC has dropped, if this wasn't a one-off issue I'm sure we'll see it again, so I'll keep an eye out. I'm 99.9% certain that our store is not being created on a background thread though.

[lukeredpath]

No sooner had I posted, another member of my team just experienced this bug - except this was on Xcode 12.5.1 on iOS 14.8.

Make sure that "ViewStore.send" is always called on the initial thread.

  Initial thread: <NSThread: 0x281df7880>{number = 10, name = main}
  Current thread: <NSThread: 0x281dac9c0>{number = 1, name = main}

The "Store" class is not thread-safe, and so all interactions with an instance of "Store" (including all of its scopes and derived view stores) must be done on the same thread.

Hmm....

[tgrapperon]

@lukeredpath If you create a dedicated init for Store and use it for your root store in your Coordinator, you can easily check which thread is running this code.

[lukeredpath]

I'm going with this for now, in the function that creates our root store:

if !Thread.isMainThread {
  assertionFailure("The main TCA store must be created on the main thread.")
}

If that never asserts and we still hit this issue, then there must be something else going on here.

[lukeredpath]

Right, looks like we can still hit this problem without the above assertion being hit which points to the underlying Thread object that represents the main thread changing - I'm just going to pair with my colleague and see if we can get more info.

[tgrapperon]

Are you sure isMainThread isn't merely checking if the name of the thread is "main"? What happens if you dump the thread where you assert?

[mbrandonw]

I'd be interested in seeing what Thread.isMainThread prints when the store is created and when the warning breakpoint is triggered. I'm wondering if thread identity can't be relied on for the main thread, but maybe isMainThread can be relied on.

We're also experimenting with using thread variables to detect this situation. I would hope that even if there are two different references for the main thread that they would at least still share the same thread variables.

[mbrandonw]

@lukeredpath Could you point your project to this branch and see if you can reproduce?

https://github.com/pointfreeco/swift-composable-architecture/tree/thread-identity