Accepting again leaved share CloudKit causing token problems

Question

Created Oct ’20

Replies 1

Boosts 0

Participants 1

I have sync troubles with CKServerChangeToken when re-accepting again CKShare. Here is the steps to explain, starting from the point when share accepted and everything synched.

Model:

List. It is parent for Items. It can be shared.
Item. Have parent List, sharing inherited from parent List.

Steps that are causing the problem:

Share accepted by user B, user A is owner, zone synched, CKServerChangeToken stored by User B.
User B's Shared Zone contains List1, List2 with some Items inside each
User B delete CKShare for List1 only from that zone in his Shared database, e.g. leaved share (shown as invited for User A now)
User B use the same link to accept share again, he is shown as accepted participant for User A, everything is fine so far.
User B perform sync operations, but turns out like nothing was changed since stored CKServerChangeToken and List1 with all it's items is being skipped on sync. CKFetchRecordZoneChangesOperation returns nothing as each of CKRecords (List1 and it's Items) was not changed. Updating List1 CKRecord solves the problem as it's a change after stored CKServerChangeToken. Also each Item CKRecord inside List1 must be updated to be detected by sync operation as updated records after CKServerChangeToken.

How to manage this issue?

Boost

Answer 1

bodich OP

Oct ’20

I've figured out what happens here. Here is what we must do after leaving share:

Leave share
Perform sync again (to get new token)!
Check if we received leaved share on step 2 at fetching because CloudKit server 50% chance will not return updated state if you will perform step 2 right after step 1. Looks like server need some short time to process updates from step 1, so we have to run step 2 for example in 2 seconds after step 1 (and anyway check step 3 after that as I have no idea if it can update it's state longer than half a second as usually).

So, I do not allow to accept any shares until step 3 (check if step 2 fetch contains share deletion) succeeded. If it return deleted share, then it's safe to accept this share again and we will get all updates correctly.

0