[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              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
-State              | Unconfirmed
+State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
-Owners             |
+Owners             | Michael Rubinsky
------------------------------------------------------------------------------


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


> I'm not sure if the listBy() / getChanges() horde app API should  
> include a change if it's exactly on the desired end timestamp or not  
> (history_ts <= $end_ts). If not, we should do a "thisSyncTS+1" query  
> in the ActiveSync backend.

Yes, it absolutely should. Otherwise that exact timestamp will never  
be included since the start_ts is always excluded.

> But there is more :) Here's a short dump from my history database:

<snip log>

> As you can see there are several entries with the same change  
> timestamp. An ActiveSync client might query for "history_ts <  
> 1365669188" and only see the first entry (id: 811). The delete  
> request via the web UI is still running and adds the second delete  
> request to the history database also with ts = 1365669188 (id: 812).
> The ActiveSync client will miss this one as it already queried for  
> all changes up to 1365669188. Classic race condition :)
>
> Any idea how to fix this one? A monotonic counter would be best but  
> that's a rather intrusive change.

This one is rather trickier. Ideally, all entries with the same ts  
should be written as an atomic action, and be guaranteed to be  
completed by the indicated ts. This is obviously not the case here  
though. We could change both the start and end ts to be inclusive in  
the query, though as you said, this would lead to changes potentially  
being picked up more than once. We could possible keep track of the  
UIDs of messages that have been changed on the last SYNC response, and  
exclude them if they occurred on the exact ts boundary. I have no idea  
if the current code would support this though (I don't have access to  
code at the moment).

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

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.