Regarding the use of _assumeIsolated in the Store.deinit

[bobspryn]

I'm seeing a crash in one certain scenario in this code in Store.swift:

 deinit { guard Thread.isMainThread else { return } MainActor._assumeIsolated { Logger.shared.log("\(storeTypeName(of: self)).deinit") } } 

It passes the isMainThread check, but crashes on assumeIsolated.

@stephencelis mentioned:

It's a queue assertion failure, so the store is deallocating off the main thread
I'd maybe try to track down a preconcurrency closure holding onto the store in a non-@sendable way
But we could also discuss removing that _assumeIsolated since it's really just there for debug logging.

I was curious how it would pass isMainThread, but not be isolated to the MainActor. ChatGPT had this to say:

Key Insight:

• Thread.isMainThread checks if you're currently executing on the main (UI) thread.
• MainActor isolation requires being specifically on the main actor’s serial executor, which guarantees sequential execution. While this is typically associated with the main thread, Swift's concurrency model doesn't strictly equate the two.

In practice, certain code paths—particularly during object destruction (deinit)—might occur synchronously on the main thread but outside of Swift concurrency’s awareness (i.e., outside the main actor's serial executor). This can happen especially if:

• You're bridging with Objective-C code or UIKit callbacks that call into Swift code synchronously.
• You're in the context of runloop events or legacy UIKit/AppKit callbacks.

When that happens, the Swift runtime doesn’t recognize this as being properly "isolated" by the main actor, and thus it crashes.

[bobspryn]

Ended up being a TimeoutTask Type that had a closure referencing the parent class of my store, called from a UIKit method on the main thread that wasn't guaranteed to be on MainActor.