Bug 1291393 - [IMAPx] IDLE flag update can be applied to a wrong message
[IMAPx] IDLE flag update can be applied to a wrong message
Status: CLOSED DUPLICATE of bug 1265684
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: evolution-data-server (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Milan Crha
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-14 13:46 EST by Simo Sorce
Modified: 2016-03-07 09:09 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-07 09:09:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Simo Sorce 2015-12-14 13:46:55 EST
Sometimes evolution gets confused when it makes some changes on one connection and receive them back on another IDEL connection, as races can happen in how things are applied.

Some details have already been provided to the maintainer directly, but I am available for further inquiries.

This is part of the explanation about the issue as exchanged via email:

> There are active three
> connections, A, C, and D. The C does the update of some other folder
> and clutter the log with a boring stuff. Connection D is used for the
> deletion, there was run the STORE of the \Deleted flag and the expunge.
> Finally the connection A is in IDLE on the same folder as the D, which
> is Lists/sssd-devel. The thins is that the A, while in IDLE, receives
> also flag changes in that folder, but not based on the UID, but based
> on the index number in the folder summary (that's how the server
> reports it).
> 
> The run is this:
> A - parses received flag changes in the folder
> C - stops IDLE and runs the flag receive in some other folder
> D - runs store on the \Deleted flag on the 4 messages
>   - while the A is still processing previously received data,
>     the D calls EXPUNGE and received confirmation immediatelly
>   - ignores EXPUNGE responses, because it run the EXPUNGE command
>   - two out of the 4 deleted messages are removed from the local
>     summary at the end of the EXPUNGE command of the connection D
> A - is still parsing old stuff
> D - goes into IDLE
> A - only now received the \Deleted flag changes being done at the
>     beginning in the connection D - that's too late, there are already
>     removed messages in the local summary, and the flags are received
>     with their sequence number, not with the UID
>   - sets the \Deleted flag on the 4 messages
>   - receives EXPUNGE notifications, but ignores them
> C - still receiving stored flags on the messages in the other folder
Comment 2 Milan Crha 2016-03-07 09:09:58 EST
Changes for this are part of the changes for bug #1265684, thus I mark this as a duplicate of it.

*** This bug has been marked as a duplicate of bug 1265684 ***

Note You need to log in before you can comment on or make changes to this bug.