Regression crashing intents and notifications

[digitaldan]

is looks like #961 changed how preferences are used on the main thread (MainActor) which is causing the notification handler to crash when loading images and also our intent handler to crash when loading anything. Adding this line before we use the Network seems to fix these issue.

       // Ensure Preferences initializes on the MainActor to avoid crashes
        await MainActor.run { _ = Preferences.shared } // <---THIS LINE ADDED

        let connections: [ConnectionConfiguration]

        if let cloudUserId,
           let instance = await Preferences.shared.storedHome(forCloudUserId: cloudUserId) {
            logger.info("Setting up network tracking for \(cloudUserId)")
            connections = await [instance.localConnectionConfig, instance.remoteConnectionConfig]
        } else {
            logger.info("Using default connection configurations")
            let homePreferences = await MainActor.run { Preferences.shared.currentHomePreferences }
            connections = await [
                homePreferences.localConnectionConfig,
                homePreferences.remoteConnectionConfig
            ]
        }

I also added await MainActor.run { _ = Preferences.shared } to all the intent handlers as well.

I'm not sure however this is really the right way to fix? To be honest, what needs to be marked as "MainActor" and does not is still not super clear to me, so while i understand why the fix works, i'm not sure if its just a cheap bandaid. I can open a PR if this is the correct approach, but would like some feedback.

here's the stack trace.

(lldb) bt
* thread #2, queue = 'com.apple.root.default-qos.cooperative', stop reason = EXC_BREAKPOINT (code=1, subcode=0x18017fe60)
    frame #0: 0x000000018017fe60 libdispatch.dylib`_dispatch_assert_queue_fail + 116
    frame #1: 0x00000001801b226c libdispatch.dylib`dispatch_assert_queue$V2.cold.1 + 136
    frame #2: 0x000000018017fde8 libdispatch.dylib`dispatch_assert_queue + 84
    frame #3: 0x0000000249b2d46c libswift_Concurrency.dylib`swift_task_isCurrentExecutorWithFlagsImpl(swift::SerialExecutorRef, swift::swift_task_is_current_executor_flag) + 288
    frame #4: 0x00000001050a884c NotificationService.debug.dylib`HomePreferences.init(id=F36EDA85-1F56-48E9-B3AC-96CB822A5271) at <stdin>:0
  * frame #5: 0x00000001050bb2d0 NotificationService.debug.dylib`Preferences.init() at Preferences.swift:157:6
    frame #6: 0x00000001050ac680 NotificationService.debug.dylib`Preferences.__allocating_init() at Preferences.swift:0
    frame #7: 0x00000001050ac640 NotificationService.debug.dylib`one-time initialization function for shared at Preferences.swift:152:32
    frame #8: 0x0000000180197278 libdispatch.dylib`_dispatch_client_callout + 12
    frame #9: 0x000000018017f3b4 libdispatch.dylib`_dispatch_once_callout + 28
    frame #10: 0x00000001050ac6d8 NotificationService.debug.dylib`Preferences.shared.unsafeMutableAddressor at Preferences.swift:152:23
    frame #11: 0x0000000104ba45d0 NotificationService.debug.dylib`NotificationServiceHandler.networkTracker() at NotificationService.swift:283:45
    frame #12: 0x0000000104ba0ed8 NotificationService.debug.dylib`NotificationServiceHandler.downloadItemImage(itemURI=Swift.String @ 0x000000010380a0a0) at NotificationService.swift:225:30
    frame #13: 0x0000000104ba0460 NotificationService.debug.dylib`NotificationServiceHandler.downloadAndAttachItemImage(itemURI=Swift.String @ 0x0000000103812be0) at NotificationService.swift:213:49
    frame #14: 0x0000000104b9a004 NotificationService.debug.dylib`closure #2 in NotificationServiceHandler.didReceive(attachmentURLString=Swift.String @ 0x0000000103812aa0, bestAttemptContent=0x0000000104404ce0, contentHandler=0x0000000104baba1c NotificationService.debug.dylib`partial apply forwarder for reabstraction thunk helper from @escaping @callee_unowned @convention(block) @Sendable (@unowned __C.UNNotificationContent) -> () to @escaping @callee_guaranteed @Sendable (@guaranteed __C.UNNotificationContent) -> () at <compiler-generated>) at NotificationService.swift:118:35

[timbms]

I wonder whether this explains the high number of crashes counted in TestFlight; NotificationsService and Intents not being part of the app they are then not reported as crash
Probably unrelated are some more issues reported by some TestFlight users:

• Media and individual title are missing
• Error when sending an item command from a notification:

[digitaldan]

Yes, i think its probably to blame for a number of issue, and the extensions are tricky b/c they tend to crash in the background and get swallowed by the OS , so its not obvious whats failing without hooking up to xcode.

I can open a PR adding await MainActor.run { _ = Preferences.shared } to a few spots which does fix the issue, but i guess my question is , is this the right fix?

[digitaldan]

Just FYI there is another possible crash i have experienced with loading "getItems()" in the intents handler i will open a PR for, but its unrelated to this.

[digitaldan]

I prepared a small PR that fixes this ☝️

[digitaldan]

Actually, there are other issues now with Actors regarding preferences. I have been spending a few hours trying to figure out timeouts in the intent handler, turns out there are calls that just never return as i think we are trying to cross actor boundaries for data. Whats interesting is that these calls just hang, and do not throw an error, so very difficult to track down, and i fear there may be more wack-a-mole fixing things where this may be causing issues.

[TAKeanice]

For me, that error occurs due to an unreachable home. Somewhere, the call gets stuck and the loading of items for that home never concludes. I can see that in the improved logging that I just pushed; the line Loaded \(items.count) items for home \(homeId) is not logged for one of the three homes I have configured. The home only has a local URL and is not reachable from the network where I currently am.

[digitaldan]

Right, but with the swift refactoring PR it hangs 100% of the time for me , have you tied it since that's been merged ? I think this is a different problem .

[TAKeanice]

If #976 includes the swift refactoring, yes, I've tried it out. Maybe the hang due to an unreachable home is just the first one and more is revealed when the unreachable home doesn't cause a hang.

[digitaldan]

So i tried it on my phone , on my home network, so all were reachable ... i assumed, but you could be very well right as that sounds very reasonable (and it could be just having multiple homes triggers it) , although @timbms was also reporting hanging, so unless we both have unreachable homes, i'm guessing its something else?

[TAKeanice]

I will solve the problem with an unreachable home this evening, and then I'll be able to see if there is more after it for me. If I can't reproduce the problem you have, I'd suggest you systematically and successively add logging before and after every async call that you suspect of haging to identify the offender. Maybe the logging that I added to your branch already gives you some new insight.

[TAKeanice]

My bad: I only tested the functionality to show items in the shortcut configuration, not to execute the shortcut afterwards. Executing the shortcut hangs for me, too. Looking into it now.

[timbms]

This is exactly what I was referring to in #976 (comment). Shortcuts shows list of items, but then the execution hangs.

[TAKeanice]

@digitaldan and @timbms I lost track of this, haven´t we fixed it yet?