[Ken Case]

Originally Posted by Greg Jones

As OmniFocus launched, it began the stalled beach ball process. I then selected it in Activity Monitor where it had turned red with the warning 'Application not responding'. I have submitted the ample process-hopefully the report will give some insight as to what is going on.

It sure does! Thanks for sending that in.

The entire time of the sample is spent in -[NSDocument _hasConflicts], a private AppKit method which presumably checks to see if there are any unresolved version-editing conflicts for your document (in this case, the OmniFocus database which is managed by NSDocument). Here's the relevant part of the call graph:

    +                                 2615 -[NSDocument _handleConflicts]  (in AppKit) + 123  [0x97b8ca73]
    +                                   2615 -[NSDocument _hasConflict]  (in AppKit) + 63  [0x97b8c9ee]
    +                                     2615 +[NSFileVersion(NSTemporaryCompatibility) unresolvedConflictsExistForItemAtURL:]  (in Foundation) + 64  [0x9381557b]
    +                                       2615 LBRevisionHasUnsavedConflictForURL  (in Librarian) + 57  [0x5fba786]
    +                                         2615 _LBFVSendMessageWithReply  (in Librarian) + 645  [0x5fba65e]
    +                                           2615 xpc_connection_send_message_with_reply_sync  (in libxpc.dylib) + 233  [0x9399bbe2]
    +                                             2615 dispatch_semaphore_wait  (in libdispatch.dylib) + 36  [0x974b48fc]
    +                                               2615 _dispatch_semaphore_wait_slow  (in libdispatch.dylib) + 117  [0x974b4800]
    +                                                 2615 semaphore_wait_trap  (in libsystem_kernel.dylib) + 10  [0x988fcc5e]

I'm not sure why this would be taking so long; until now, I didn't realize that that conflict check was happening at all when opening an OmniFocus "document", or that that check involved a separate process. (Looking at the lower bits of that call graph, it's sending a message to another process and spending all its time waiting for that process to reply.)

Making this even more challenging is that we're not seeing this problem ourselves, so we can't reproduce it to try to figure out if there's something we can do to avoid tickling the behavior. But I'll run it past the rest of the team to see if anyone has any ideas.

P.S. — It's possible that whatever process we're calling out to would show up in Activity Monitor as busy during that time; if so, it might be helpful to know what process that is.