[Tickets #12175] Re: ActiveSync misses changes from history database

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12175
------------------------------------------------------------------------------
  Ticket             | 12175
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | ActiveSync misses changes from history database
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-04-11 15:10) wrote:

>> The other possibility would be to somehow track the most recent
>> history id detected. Though I really don't like this approach since
>> it means the client code would need knowledge of how they history
>> system functions - and it assumes any history backend would both have
>> some unique entry identifier, and those identifiers are numeric (or
>> at least increase in some numeric-like fashion).
>
> My idea of abusing the history_id as monotonic counter is doomed anway:
> In the Kolab world, an object can disappear and re-appear. So a  
> history database entry with a low id might have a current timestamp  
> and therefore be missed again.
>
>> Both approaches would require some API changes to both the activesync
>> code as well as the history code in order to provide the needed data
>> - and such changes would need to maintain BC.
>
> It seems like a good idea to keep an array of seen object UIDs  
> during the last sync timestamp window (start_ts <= x <= end_ts). We  
> would also need to keep this list for every action (add, modify,  
> delete).

Yeah, though this seems like a lot of extra overhead, between creating  
the entries, checking the entries, expiring the entries... On the  
other hand, we already have code in place to exclude sending changes  
to the client that were the result of changes DUE to the client. E.g.,  
changing a contact on the device still causes a history entry to be  
created, but we must ignore that entry since the client is the one who  
made the change in the first place. Perhaps if we need to go this  
route, we could utilize the same system for this as well. Again, I'm  
saying all of this without looking at code...

> We can start expiring entries in this list once the current  
> "start_ts" is higher than the last noted end_ts.
>
> That still leaves one problem: If an object gets changed twice  
> during the same second and a client already saw the first change, it  
> will miss the second change. This risk is rather low but it will  
> happen sooner or later.

Exactly. We would be exchanging one issue for another.


> Only a monotonic counter will solve this. Let's see if we can come  
> up with a simpler solution...

The more I think about it, I think my previous suggestion of either  
having the history system increment the ts before writing it, or  
activesync decrementing the end_ts before querying is the way to go.  
There will still be a slight change of this still happening but if the  
history system can't guarantee an entry is available within something  
like 10 to 20 seconds of the time it is stamped with,than there are  
bigger problems with the API itself here...