[Tickets #12567] AS: Unlikely race condition leads to data loss

[noreply at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/12567
------------------------------------------------------------------------------
  Ticket             | 12567
  Created By         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  Summary            | AS: Unlikely race condition leads to data loss
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-08-13 10:28) wrote:

Hi,

after intensive torture testing the ActiveSync code and day-long
email exchange with Michael ([mjr]) (thanks for your help!)
I figured out this scenario were the current sync engine
might skip a change on the server:

----------------------------------------------------------------
(1) Client sends a SYNC request to the server.
     It notes 10 as the last used modseq in the syncState.

(2) Client sends a change to the server. We import the change
     via _as->driver->ChangeMessage(). Internally that function
     is split into non-atomic parts (2a) and (2b).

(2a) We store the change via the API into the backend.
     The modseq stored in the history table is 13.

(x) Someone else does a change to the same object.
     The modseq stored in the history table is 16.

(2b) ChangeMessage() finally calls smartStatMessage() on "our"
      change from (2a). We will return 16 as the modseq.

(3) We insert the sync_key, the returned modseq and the object_uid  
into the syncMap.
     This will insert the modseq 16 into the syncMap.

(4) The client sends his SYNC request.
     The last sync request was at 10, so it will grab
     all changes between 10 and 16.

(5) The server part sees the MODIFY change for the object_uid sent in (2)
     It will call $backend->statMessage() and return 16 for this message.
     getPIMChangeTS(object_uid) will also return 16.

     As $pim_ts(=16) is >= $stat['mod'](=16) we ignore the
     change as originating from the PIM even though another
     user changed the object.
----------------------------------------------------------------

The root issue here is that the API and the horde apps don't
transport the modseq value after doing a change in Horde_History.

Transporting this value back to the ActiveSync layer is complex
surgery and not doable in a BC way. We needed to come up with another  
solution.
I'll add the proposed solution in a separate message.

Thomas