The logic that stops us from trying to synchronize to the dawn of time appears to have regressed during the refactoring to integrate ActiveSync sync. It didn't get a unit test because of time pressure; it definitely needs one now. The way to force a folder into the situation that causes this logic is to make sure there is a \Deleted but not expunged message in the folder. The test will need to use a time shift or trickery to make sure we do the iterative deepening sync logic and that the sync logic goes all the way back to the time threshold in question.
This bug will occur in folders with deleted but not expunged messages when synchronization reaches the end of the available message. It is most likely to manifest in folders with less than 15 non-deleted messages. It will manifest as a very long, if not neverending, series of search requests issued against the server. On yahoo.com, once we get back to 1884 the server appears to have a bug and it starts telling us about recent messages again. This may appear more frequently and with significantly worse ramification when other synchronization bugs cause us to fail to synchronize messages.
blocking-basecamp: --- → ?
The fix has been reviewed and landed in upstream gaia-email-libs-and-more: https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/6d697e2bed2c8de8789d74ad0f964e305a5a1ac9 Waiting on approval to land on gaia.
Blocking+, shouldn't sync to the dawn of time.
blocking-basecamp: ? → +
Landed on gaia master: https://github.com/mozilla-b2g/gaia/commit/3324844835a4ecfe7df1f36ad8c7d5fd805ea8a9
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Device: Unagi Build: 20130112070202 Does not reproduce at this time.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.