[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
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
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