Tickets :: Comment on [#12506] Contacts sync with ActiveSync get duplicates and not sync

* Your Email Address
* Spam protection	Enter the letters below: .__.._..___. ..__ [__] \| _/ \|[__) \| \|_\|_./__.\__\|\|
Comment	>> I think that something should be used to limit this problem somehow, >> blocking android device if we detect this problem or something. Don't >> know how. > > We already attempt to detect duplicate additions from the client by > using the only bit of uniquely identifying data the client provides > with new entries - the ClientEntryId value. The client is supposed to > save this value until it receives a response from the server mapping > a server UID with the ClientEntryId. The problem in your case is that > your client is sending a different value for this field with each > attempt. This could be because the client is receiving some of the > responses before timing out, but if it decides the sync is > unsuccessful, it should not regenerate those ids. > > What I don't understand yet though is why Turba is letting the > duplicates be added. There is code in Turba_Api::import() that is > supposed to reject entries that contain the exact same data (current > Git - Turba/lib/Api.php line 745. You can add some debug logging > there and compare the value of $content for each attempt. > >> 2. About the real timeout issue, I was thinking about limiting and >> accepting just 20 entries from the phone at a time. >> I am not an ActiveSync expert, should this work or you must accept >> the full sync? > > This is what I meant when I said that there is no mechanism in place > to page incoming changes. All incoming requests must be handled, or > an explicit error code for the failure must be sent...and there is no > error code for "Too many messages sent". Simply ignoring the other > entries will cause the device to believe that they have been > successfully added when in fact they have not. This is per the EAS > specs. The reverse is not true - the client will only request a > subset of all server changes at a time.
Attachment
Watch this ticket

Saved Queries