6.0.0-alpha12
▾
Tasks
New Task
Search
▾
Others
Photos
Wiki
Development
Tickets
New Ticket
Search
Toggle Alerts Log
Help
7/11/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
>> Later, as the client device does not see any reply for these entries >> it tries to upload them again and again and again... dups detected, >> of course, but this is bad. > > Well, from what you told me earlier, your device is not receiving > *any* response from the server before it closes the connection. It > doesn't matter what response we send if the client never sees it. > >> Looking at EAS docs maybe a Status 7 should be replied? >> http://msdn.microsoft.com/en-us/library/gg675457%28v=exchg.80%29.aspx >> === >> 7 > > No, STATUS_CONFLICT is only to be used with an item successfully > synced by the client (the client knows the item's server-side UID) > that has changed on both the client and server. > > What probably should happen is when a duplicate addition is detected > we should return the existing item's UID as if the addition was > successful. Of course, I have no idea what your client will do with > this, since it is demonstrating broken behavior anyway, not to > mention if the connection continues to timeout, this won't help your > original problem anyway. As I said before uploading hundreds of new > messages from the client to the server is NOT something the protocol > was originally designed to handle. > >> On the other hand, it seems interesting that if the Android device >> doesn't see any status reply for some items it behaves like if they >> were not accepted by the server and try again. > > No, in fact it's the exact opposite (though I agree the spec doesn't > make much sense here). From MS-ASCMD 2.2.3.7: > > == > The server is not required to send an individual response for every > operation that is sent by the client. The client only receives > responses for successful additions and fetches, and failed changes > and deletions. When the client does not receive a response, the > client MUST assume that the operation succeeded unless informed > otherwise. > == > > So, no, the client should NOT resend an item if it does not receive > ANY status response. Of course, for client -> server additions the > behavior of any further actions would be undetermined since the > client would not know the server's UID. Rather, from what you told me > earlier, your client is resending the messages because it did not > receive ANY response before the connection was closed. > >> Maybe this could be >> used for pacing the client uploads. > > No. As stated earlier, there is no paging of the client uploads in > the EAS protocol. Attempting to abuse some status code that should > have another meaning is nothing more that a hack to get around broken > client behavior. > >
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