[Tickets #13825] Re: Remi PHP update to 5.5.21-1 results in constant resyncing

[noreply at bugs.horde.org]

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

Ticket URL: https://bugs.horde.org/ticket/13825
------------------------------------------------------------------------------
  Ticket             | 13825
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Remi PHP update to 5.5.21-1 results in constant
                     | resyncing
  Queue              | Synchronization
  Version            | FRAMEWORK_5_2
  Type               | Bug
-State              | Unconfirmed
+State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2015-01-23 14:46) wrote:


> Then I realized I updated PHP and that the php-imap package was  
> among the updates. I downgraded all PHP packages to the old version  
> and everything works like a charm now.

Horde/IMP does not make use of the PHP bundled IMAP library. We use  
our own Horde_Imap_Client library. If this issue is, in fact, due to a  
PHP update, it is not from php-imap. Any other errors in the webserver  
error log, or the horde log?


> The reason why I'm filing this bug is: I think Horde should handle  
> the above error message and tell the ActiveSync client to try again  
> later. I suspect that Horde reported back to the client that no  
> message at all is left in the folder it tried to sync when the error  
> occurs, and with the next ping it is able to connect again and  
> resyncs all the messages.

Normally, when an error such as the one you describe occurs, we report  
the error condition back to the client (as we should). What the client  
chooses to do with that information is out of our control. I'd have to  
see more context in the sync log to see if we are sending the most  
appropriate error code back or not. Depending on when the error  
occurs, and what the actual error is, we might not have the chance to  
send an error code back. Again, would need to see more context to know  
for sure.