6.0.0-alpha12
▾
Tasks
New Task
Search
▾
Others
Photos
Wiki
Development
Tickets
New Ticket
Search
Toggle Alerts Log
Help
7/1/25
H
istory
A
ttachments
C
omment
W
atch
Download
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
N
ew Ticket
M
y Tickets
S
earch
Q
uery Builder
R
eports
Saved Queries
Open Bugs
Bugs waiting for Feedback
Open Bugs in Releases
Open Enhancements
Enhancements waiting for Feedback
Bugs with Patches
Enhancements with Patches
Release Showstoppers
Stalled Tickets
New Tickets
Horde 5 Showstoppers