Summary | Poll response broken after showMessage requests |
Queue | IMP |
Queue Version | Git master |
Type | Bug |
State | Not A Bug |
Priority | 1. Low |
Owners | slusarz (at) horde (dot) org |
Requester | jan (at) horde (dot) org |
Created | 03/30/2012 (4844 days ago) |
Due | |
Updated | 04/05/2012 (4838 days ago) |
Assigned | 04/02/2012 (4841 days ago) |
Resolved | 04/05/2012 (4838 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Not A Bug
I.e. would the cache correctly be expired if users upgrade to the
next version, or will they see cache corruption too?
(not yet released) in Horde_Imap_Client.
I.e. would the cache correctly be expired if users upgrade to the next
version, or will they see cache corruption too?
one of the unseen messages. After that, the unseen count is still at
4.
C: 2 EXAMINE INBOX.horde.bugs (QRESYNC (1082203163 348 0:2, [...]
This indicates you haven't cleared your cache since the imap cache
fixes were implemented. Can you try clearing your cache and try again?
This could be why this is occurring after viewing a message:
9aa2c4b715a8dfd5fe17303e4a0d4d07)
New Attachment: imap.log
of the unseen messages. After that, the unseen count is still at 4.
statusMultiple() implementation for your IMAP server?
I'm seeing this in my IMAP log:
C: 6 SEARCH RETURN (COUNT) UNSEEN
S: * ESEARCH (TAG "6") COUNT 0
S: 6 OK Search completed (0.000 secs).
State ⇒ Feedback
statusMultiple() implementation for your IMAP server?
I'm seeing this in my IMAP log:
C: 6 SEARCH RETURN (COUNT) UNSEEN
S: * ESEARCH (TAG "6") COUNT 0
S: 6 OK Search completed (0.000 secs).
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Poll response broken after showMessage requests
Queue ⇒ IMP
Assigned to Michael Slusarz
Milestone ⇒
Patch ⇒ No
State ⇒ Assigned
contains the old new-message-count from before viewing the message.
The count status is not updated in the folder list until the next
request with a poll response.