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

noreply at bugs.horde.org noreply at bugs.horde.org
Mon Jul 29 23:22:26 UTC 2013


Ticket URL: http://bugs.horde.org/ticket/12506
  Ticket             | 12506
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Contacts sync with ActiveSync get duplicates and not
                     | sync
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Not A Bug
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |

Michael Rubinsky <mrubinsk at horde.org> (2013-07-29 23:22) wrote:

> 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.

More information about the bugs mailing list