Summary | Activesync push for empty folders loops |
Queue | Synchronization |
Queue Version | Git master |
Type | Bug |
State | Resolved |
Priority | 1. Low |
Owners | mrubinsk (at) horde (dot) org |
Requester | horde (at) albasoft (dot) com |
Created | 12/06/2012 (4593 days ago) |
Due | |
Updated | 12/07/2012 (4592 days ago) |
Assigned | |
Resolved | 12/07/2012 (4592 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Resolved
Priority ⇒ 1. Low
commit 4ed1a003f5b113c2f87f92df53bcc781fb33d821
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date: Fri Dec 7 14:36:56 2012 -0500
Bug: 11823Fix initial pairing of empty folders..../lib/Horde/ActiveSync/Request/Sync.php | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/4ed1a003f5b113c2f87f92df53bcc781fb33d821
Priority ⇒ 2. Medium
Patch ⇒ No
Milestone ⇒
Queue ⇒ Synchronization
Summary ⇒ Activesync push for empty folders loops
Type ⇒ Bug
State ⇒ Unconfirmed
when the folder is empty, forcing the device to launch a SYNC command
that will return no messages. And over again.
I've searched into the code and this is my report:
- First SYNC command (synckey 0) for an empty IMAP folder creates a
new folder object with yet no status information (uidnext undef), and
saves state to database at the end of folder sync (s:1:"s";a:0:{}).
- Second SYNC command (synckey {}1) for that folder loads state from
database (no uidnext) and then runs message diff engine, getting the
IMAP folder uidnext for its first time. If there were email messages,
they would be sent and folder status saved again to database at end of
folder sync, with proper uidnext. But there are no messages, and state
is not saved to database, so uidnext remains undef.
- Then device sends a PING for that folder. Folder state is loaded
from database, with uidnext still undef. Then diff engine is launched,
but uidnext is still undef and when checking against real IMAP folder
uidnext (0 <> xx) it will always report changes available, returning
PING status 2.
- Third SYNC command from device, forced by PING status 2, will be
exactly as previous second SYNC: no new messages but folder status
will not be update with proper uidnext.
- Devices sends a new PING, and these two steps repeat many times
until device desists.
I think that uidnext value should be updated to database folder state
at some point in a SYNC command, so diff engine on a PING command
could find that real and saved uidnext values are equal and report no
changes to device.