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

[noreply at bugs.horde.org]

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              | Resolved
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-08-03 15:59) wrote:

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