When: you share your store between the app and its extensions using an App Group, an app update includes a lightweight migration Is there a risk that more than one process (eg: a background task and a widget extension) try to migrate the store at the same time? What happens then? Can it be problematic?

I'm processing history as presented in Synchronizing a local store to the cloud but I'm puzzled by some NSPersistentStoreRemoteChangeNotification that don't have any NSPersistentHistoryTokenKey ("historyToken"). Several notifications are emitted (launching the app is enough to get them reliably), and the userInfo only has the NSStoreUUID and storeURL, but no historyToken. My app performs background operations that need to be canceled if there is new history to be processed, but these empty notifications means that they are canceled/resumed for nothing. Here's what's happening in the logs before the post CoreData: sql: BEGIN TRANSACTION CoreData: annotation: connection 0x14a05e350 adopting snapshot: ss value: {length = 48, bytes = 0x18e22d00 00000000 02000000 01000010 ... ce67e038 c22b1d42 } pointer value:_PFSQLiteSnapshotWrapper (0x14a38ffa0) : {length = 48, bytes = 0x18e22d00 00000000 02000000 01000010 ... ce67e038 c22b1d42 } pointer: 0x14a390020 CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZBOOLVALUENUM, t0.ZDATEVALUE, t0.ZINTEGERVALUE, t0.ZKEY, t0.ZSTRINGVALUE, t0.ZTRANSFORMEDVALUE FROM ANSCKMETADATAENTRY t0 WHERE t0.ZKEY IN (?) CoreData: annotation: sql connection fetch time: 0.0002s CoreData: annotation: total fetch execution time: 0.0004s for 1 rows. CoreData: sql: COMMIT CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZBOOLVALUENUM, t0.ZDATEVALUE, t0.ZINTEGERVALUE, t0.ZKEY, t0.ZSTRINGVALUE, t0.ZTRANSFORMEDVALUE FROM ANSCKMETADATAENTRY t0 WHERE t0.Z_PK = ? CoreData: annotation: sql connection fetch time: 0.0002s CoreData: annotation: total fetch execution time: 0.0004s for 1 rows. CoreData: annotation: fault fulfilled from database for : 0x87dcfb0ae3b5ee85 <x-coredata://18A3AE76-9F1F-4153-8410-F15A01AED530/NSCKMetadataEntry/p2> CoreData: sql: BEGIN EXCLUSIVE CoreData: sql: UPDATE OR FAIL ANSCKMETADATAENTRY SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT = ? CoreData: sql: COMMIT CoreData: sql: BEGIN TRANSACTION CoreData: annotation: connection 0x14a05e350 created snapshot: ss {length = 48, bytes = 0x18e22d00 00000000 03000000 01000010 ... 5708fa9b fd63878d } value: pointer value:{length = 8, bytes = 0x6019394a01000000} pointer: 0x14a391960 CoreData: sql: ROLLBACK CoreData: debug: Remote Change Notification - Posting for com.apple.coredata.NSPersistentStoreRemoteChangeNotification.remotenotification.18A3AE76-9F1F-4153-8410-F15A01AED530 CoreData: debug: Remote Change Notification - observer received for 18A3AE76-9F1F-4153-8410-F15A01AED530 with state 0 CoreData: sql: SELECT MAX(Z_PK) FROM ATRANSACTION CoreData: debug: Remote Change Notification - PSC to post notification for store 18A3AE76-9F1F-4153-8410-F15A01AED530 with transaction ID 0 CoreData: sql: BEGIN TRANSACTION CoreData: annotation: connection 0x14a05e350 adopting snapshot: ss value: {length = 48, bytes = 0x18e22d00 00000000 03000000 01000010 ... 5708fa9b fd63878d } pointer value:_PFSQLiteSnapshotWrapper (0x14a3926f0) : {length = 48, bytes = 0x18e22d00 00000000 03000000 01000010 ... 5708fa9b fd63878d } pointer: 0x14a391960 CoreData: debug: Remote Change Notification - posting for store 18A3AE76-9F1F-4153-8410-F15A01AED530 with userInfo Adding a guard clause to skip history processing when the NSPersistentHistoryTokenKey is missing seems fine, but I'd rather make sure this is a safe thing to do, and for that I'd like to understand why these "empty" notifications happen and what their purpose is.