Going to resolve until somebody can provide reliable steps to reproduce.

Unfortunately, I don't see the cause for the failed sync in this 
portion of the log.

I've added some additional logging to the code, and also changed it so 
we no longer clear the sync state when this happens. This will at 
least prevent the client from continuously trying over and over again 
after it reaches this point.

That didn't work either - here's a link

https://dl.dropboxusercontent.com/u/203576/49F0F79FA24A4D73889C1F0A61C274CC-1.zip

Hmm, didn't like me using the same attachment name. Renamed to "4...-1.zip"

This should be better, I see some "INSERT INTO" errors in there - 
they're probably important ;-)

Yes.
Multiple cycles of <SYNC> request and responses with the same <SYNCKEY> value.
Maybe?

OK how do I get that? Is that the same file - just with more data in 
it? What should I look for so I know when it contains what you need? 
(ie the file is now twice as large as the one I sent through - will 
that contain what you need?)

No, it's not the cause of the problem, but rather a result of it. It 
means the client is continuously requesting the same synckey over and 
over again - probably because it didn't like some data it received in 
the response. I would need a synclog that shows the full cycle of 
request/response that keeps repeating (this contains only a portion of 
the last response).

Hi there

Sorry, but the issue returned. Very strange - before it was Outlook 
2013 that worked and Android that couldn't update, whereas now Android 
is working fine, but Outlook 2013 cannot update!

Attached is the ActiveSync logfile for Outlook. The "ERR: Reached 
MAXIMUM_SYNCKEY_COUNT possible sync loop" looks like where the problem 
begins?

Thanks to your reference to the other bug, by reading about that I 
decided to reinitialize the entire horde database.  That fixed the 
problem

i.e. it appears the upgrade from 5.0 to 5.1 involves a bunch of SQL 
schema changes, and something went wrong in there - leading to this 
problem?

I did backup the original database, so if you need "chunks" that could 
show the problem, let me know

Jason

Going to resolve this one to avoid confusing it with Bug: 12316. This 
bug was a regression of an earlier fixed bug, not related to the 
"Unknown Message" bug in the other ticket.

Thanks for this clarification. At least I know the UIDVALIDITY code is 
working as intended.
This is Bug: 12316

I'm using courier-imap and it has a courierimapuids file that contains 
the uid mappings to Maildir files. I just deleted the one for my 
inbox, and made my (imap) Thunderbird "repair folder" - which forced 
courier-imap to generate it. Both Outlook and Android certainly 
noticed the change, spontaneously did a "re-jig" and suddenly my 
Android was up-to-date again. However, I just sent a new message in 
and it didn't show up on the Android or Outlook - but did on TB - so 
it's out of whack again

Attached is the Outlook sync log. I captured this after the above changes

Bug: 12316
This is happening because, for some reason you are getting UIDs back 
from your IMAP server that are lower than the minimum UID received in 
the initial sync. No idea why this is happening at this point. My 
guess is that the UIDs are no longer valid (UIDVALIDITY changed), but 
I'm waiting for someone to test those changes.
Yes, that's how ActiveSync works. The difference with Outlook is that 
it syncs EVERY email folder COMPLETELY and pushes every folder, 
whereas android, by default, only pushes INBOX. Now, if it's actually 
issuing continuous SYNC requests (and not looping within the single 
SYNC request) then *that* is a problem.
This setting is simply the time that each PING or SYNC request lasts 
before initiating another one, so you will still see the checks. If 
you want to reduce the number of actual checks performed during each 
heartbeat you should increase the 'waitinterval' setting. This will 
cause the server to wait longer between backend checks. Of course, 
this also means it will be longer before the change is detected and 
therefore longer to be pushed to the device.
Not a corrupt email, but unexpected (or unexplained) email UIDs being 
received from the imap client.
No idea how Outllook is getting past this. A log from Outlook would 
possibly be helpful as well.

Attached.maybe the following is the report of the problem?

ERR: Unknown message.

Now that I've enabled per-device sync logging, I can see something 
else. My Android is blocking on this error (I guess), but the traffic 
storm I'm seeing is actually from my Outlook 2013 - it's log file is 
huge and growing by megabytes per minute (60,100 lines per minute). 
However, email seems to be in sync - it's simply continually checking? 
I have set "forcedheartbeat" in an attempt to slow down Outlook - but 
even after a restart doesn't seem to have any effect

I'm guessing there's a corrupt email that causes Android to fault and 
stop, whereas Outlook gets past it but then goes back to re-check and 
ends up looping?

Just guesses :-)

Thanks

Jason

The sync log, attach to ticket please.

I think I'm seeing this too. I was happily running 5.0.X until this 
week when I updated to 5.1.X. Since then, ActiveSync has become 
basically broken. Android phones are continually resynching - never 
finishing.

From a fresh reset they successfully download mail, but then can 
never get updates. The logs show continuous " 200 " download activity, 
but nothing new shows up in the device

I have manually applied the two patches mentioned in this ticket but 
they haven't helped.

I can get you logs if you want to know what we're seeing - just let me 
know what you need

I'm not sure, since the problem did not always occur. I have been 
experimenting with a NoSQL cache (MongoDB) lately and noticed a few 
times when I restarted Apache and/or MongoDB. It happened three times 
so far and I only noticed it because of the *huge* battery drain on 
the respective phones. I'll keep an eye on it. If it doesn't happen 
again in the next few days, it is most likely resolved by these changes.

Does this fix?

Changes have been made in Git (master):

commit e8b8ebb65de1d70ff92ef1b010a58a00e12c3577
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Tue Jun 11 16:43:30 2013 -0400

     Bug: 12339 Fix regression of Bug: 12075 in preventing PING-SYNC loop.

  .../lib/Horde/ActiveSync/Collections.php           |    3 +++
  .../lib/Horde/ActiveSync/Request/Ping.php          |    1 +
  2 files changed, 4 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/e8b8ebb65de1d70ff92ef1b010a58a00e12c3577

For the record, this is with Horde_ActiveSync-2.4.0.

Bug http://bugs.horde.org/ticket/12075 is back in Horde-5.1.0.

The behavior is identical, the loop is broken by forcing a flag change 
or new messages in the folder where this happens.

Log of two iterations attached.