[Tickets #12605] Re: AS: Fix loss of PINGABLE flag

[noreply at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/12605
------------------------------------------------------------------------------
  Ticket             | 12605
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | AS: Fix loss of PINGABLE flag
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-08-23 13:59) wrote:

> Hi,
>
> I just noticed that I had to open the email application on my iPod  
> to see new messages,
> email push was broken somehow. Reading through the logs I noticed it  
> complained the INBOX "collection" is not pingable.
>
> It turned out that the function to update the pingable state of a folder
> a) checked the wrong key name and b) checked it on the wrong variable.
> Two bugs in one line :o)
>
> Attached patch fixes the issue.
>
> I guess we need to fix this up in the database or use some other
> kind of mechanism to trigger an updatePingableFlag() call:
> I had to disable and re-enable email sync on the iPod to fix it.
>
> Thomas
>

This isn't correct. The idea behind the "PINGABLE" flag is to remember  
which collections were requested in the last full PING request so that  
when the client issues an empty PING request the next time around we  
know which collections to ask for. Just because we have a collection  
(in the cache) with a synckey does not mean that we want to PING it.

This method should only be called during a full PING request (one in  
which all collections the client is interested in PINGing is  
included). $this->_collections contains all the *currently* loaded  
collections that were requested during the current request.  
$collections (in the loop) contains ALL collections we know about.

I think what is happening here is that for some reason, the client is  
issuing a PING request without the email folder, so the email  
collection's ping flag is reset. Why it is issuing this request is  
another story...wild guess - maybe an error in the email collection at  
some point prompted the client to stop trying?