517461 - Perfolder unread e-mail count sometimes is wrong on a IMAP server (IMAP server, dovecot, supports CONDSTORE)

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Paragina]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4

This happens on a dovecot IMAP server (just in case it matters). Starting with a clean profile, just to be sure it's not an folder issue with the prior thunderbird 2, which is still installed. (I create a new profile with thunderbird -profilemanger, leaving the thunderbird 2 profile untouched).
Thunderbird starts scanning for e-mails. When I first enter the folders the number is correct. After a while, on some folders, when entering, the unread count changes to a wrong number.

Intresting enough I haven't seen this happening on the main INBOX folder. But considering the randomness of the bug I can't say that it doesn't happen on INBOX.

Here are some random folders form my inbox (sidenot the bug seems to manifest on folders with a lot of e-mails)

"folder path" "webmail(read/unread)" "thunderbird 3b4(read/unread)"

inbox 3/1356 3/1356

Mailing Lists/Facultate/info 2009 5/1510 4(this was also 7 while creating this report)/1499
Mailing Lists/funny 9/9 9/9
Mailing Lists/puppet 15/896 1/896
Mailing Lists/xen/xen-dev 187/1191 1/1191
Mailing Lists/xen/xen-user 34/703 1/703
OMG/Code Project 2/399 2/399
mentenanta/gate 14/2426 15/2426




Reproducible: Sometimes

Steps to Reproduce:
I can't say some exact steps, please read the details.
Actual Results:  
Number of unread e-mails changes.

Expected Results:  
Display the right number of unread e-mails from imap

Thunderbird 3 Beta 4 from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0b4-candidates/build4/win32/en-US/

Comment 1

[Paragina]

Another thing discovered just now. Some folders seem to be linked or something alike. 

2 folders that behave like this are puppet (from the last comment) and sent. Whenever the count gets incremented on puppet the sent folder receives the same count when I open it (not before). So the e-mails/folders get mixed up on this count.

Comment 2

[Wayne Mery (:wsmwk)]

is this known to also be a problem in v2?  If not, this is regression.

Incorrect message counts don't constitute a "major" loss of functionality (see [1]), and historically are more like minor. though no doubt annoying has h***.

[1] https://bugzilla.mozilla.org/page.cgi?id=fields.html#importance

Comment 3

[Paragina]

Thunderbird v2 no.
Beta 2 not sure I did not test beta 2 enough to say yes or no. If you wish I can.
Sorry about the major thing, it seemed so, I personally can not use it if it works like that so that was my logic.
If I can help you with anything shoot.

Thank you,
  Silviu

Comment 4

[Dave Brooks]

I'm seeing exactly this -- with TB 3b3, b4, rc1 and Shredder 3.0.1pre. IMAP server is Dovecot, client system OS/X.

Thanks,
Dave

Comment 5

[Dave Brooks]

Also this behaviour is reproducible, both with a totally clean install (removing profile folder and preferences) and following an upgrade. I'm happy to test with a debug/logging version if there's one available.

Dave.

Comment 6

[Ludovic Hirlimann [:Usul]]

Dave can you provide us with a IMAP log as described at https://wiki.mozilla.org/MailNews:Logging ?

Comment 7

[Dave Brooks]

(In reply to comment #6)
> Dave can you provide us with a IMAP log as described at
> https://wiki.mozilla.org/MailNews:Logging ?
 
I now have a 2.5GB log file! :) This is from running TB3-rc1 after removing my existing profile plus preferences and then letting indexing etc happen until the unread folder list showed a folder with the wrong unread count.

This particular folder has 69 messages in it, 20 of which are unread (as per a webmail interface to the IMAP server).  Searching the log file for FETCH responses for the folder confirms these figures -- TB got 69 FETCH results of which 20 did not have the Seen flag set.

So whatever has gone wrong is internal to TB.

I have saved the profile folder and its contents. Where should I be looking to see what TB has cached? Is it in an msf file? Where is the format described? Or in the global-messages-db.sqlite database? (I can see the folder in the folderLocations table yet the messages table only has four rows with that folderID  -- should there be 69 rows??).

Thanks,
Dave

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #7)
> I now have a 2.5GB log file! :)

dovecot can support "CONDSTORE" extension.
Dave Brooks, can you search log file for "CONDSTORE".
If "CONDSTORE" is found, it's possibly same issue as bug 530551 or bug 532059.

Comment 9

[Dave Brooks]

(In reply to comment #8)
> (In reply to comment #7)
> > I now have a 2.5GB log file! :)
> 
> dovecot can support "CONDSTORE" extension.
> Dave Brooks, can you search log file for "CONDSTORE".
> If "CONDSTORE" is found, it's possibly same issue as bug 530551 or bug 532059.

Yes, the log has CONDSTOREs in it -- I'll try disabling mail.server.default.use_condstore as per bug 530551 and see how things go.

Thanks.

Comment 10

[Dave Brooks]

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > I now have a 2.5GB log file! :)
> > 
> > dovecot can support "CONDSTORE" extension.
> > Dave Brooks, can you search log file for "CONDSTORE".
> > If "CONDSTORE" is found, it's possibly same issue as bug 530551 or bug 532059.
> 
> Yes, the log has CONDSTOREs in it -- I'll try disabling
> mail.server.default.use_condstore as per bug 530551 and see how things go.
> 
> Thanks.

YES! Setting mail.server.default.use_condstore to false fixes things.

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
> YES! Setting mail.server.default.use_condstore to false fixes things.

Thanks for your information. I'm now convinced by your comment that bug 517461(this bug), bug 530551, and bug 532059, are for same issue which is caused by Tb's CONDSTORE support or server side CONDSTORE support.
Dave Brooks, can you get minimum IMAP log to analyze problem with CONDSTORE?

Comment 12

[WADA:World Anti-bad-Duping Agency]

To Paragina(bug opener):
Can you get IMAP log? Is there "CONDSTORE" in IMAP log?

Comment 13

[WADA:World Anti-bad-Duping Agency]

Putting bug 530551 and bug 532059 in dependency, and adding "CONDSTORE" to bug summary, for ease of search and tracking.
Paragina(bug opener), please remove them if your case is irrelevant to CONDSTORE.

Comment 14

[Dave Brooks]

(In reply to comment #11)
> (In reply to comment #10)
> > YES! Setting mail.server.default.use_condstore to false fixes things.
> 
> Thanks for your information. I'm now convinced by your comment that bug
> 517461(this bug), bug 530551, and bug 532059, are for same issue which is
> caused by Tb's CONDSTORE support or server side CONDSTORE support.
> Dave Brooks, can you get minimum IMAP log to analyze problem with CONDSTORE?

TB3 b3 on OS/X
IMAP server Dovecot 1.2.rc2
TBird initially has CONDSTORE enabled.

Testing was as follows:
1. TB running, logging to imap_SM1.log
2. Exited TB
3. TB running, logging to imap_SM2.log
4. Noticed the read message count for the "Suppliers.Banking and IRD" folder changing from 2 to 1. There are in fact 2 unread messages, verified by a webmail client.
5. Set mail.server.default.use_condstore to false
6. Exited TB
7. TB running, logging to imap_SM3.log
8. Click on the "Banking and IRD" folder in the unread messages pane. The unread message count changes from 1 to 2.
9. Exited TB
10. TB running, logging to imap_SM4.log
11. Set mail.server.default.use_condstore to true
12. Exited TB
13. TB running, logging to imap_SM5.log
14. Wait a bit. A folder called "Suppliers.Accutime Systems" shows up in the unread folders pane with 4 unread messages when in fact it has none.
15. The read message count for "Banking and IRD" folder then changed from 2 to 1.
16. Set mail.server.default.use_condstore to false
17. Exited TB
18. TB running, logging to imap_SM6.log
19. Click on the "Accutime Systems" folder in the unread messages pane. The unread message count changes from 4 to 0.
20. Click on the "Banking and IRD" folder in the unread messages pane. The unread message count changes from 1 to 2.
21. Exited TB
22. grep Accutime imap_SM*.log > accutime.log
23. grep Banking imap_SM*.log > banking.log
24. Log extracts are attached.

Comment 15

[Dave Brooks]

Attachment: As per comment 14

Comment 16

[Dave Brooks]

Attachment: As per comment 14

Comment 17

[Dave Brooks]

(In reply to comment #14)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > YES! Setting mail.server.default.use_condstore to false fixes things.
> > 
> > Thanks for your information. I'm now convinced by your comment that bug
> > 517461(this bug), bug 530551, and bug 532059, are for same issue which is
> > caused by Tb's CONDSTORE support or server side CONDSTORE support.
> > Dave Brooks, can you get minimum IMAP log to analyze problem with CONDSTORE?
> 
> TB3 b3 on OS/X
> IMAP server Dovecot 1.2.rc2
> TBird initially has CONDSTORE enabled.
> 

Further comments:
1. I've upgraded Dovecot to 1.2.8 -- it's made no difference.
2. A restart of TB is needed (after setting use_condstore) to start things going wrong. Once a stable state (of wrong read counts) is reached then I can mark messages read/unread and TB's count will change accordingly. (TB normally runs until I restart OS/X, which can be a few weeks).
3. The state of Global Search/Indexer doesn't make any difference, although if it's enabled then the unread counts turn up sooner (as mail folders are scanned).

Comment 18

[WADA:World Anti-bad-Duping Agency]

Dave Brooks, thanks for getting IMAP log.
If you test next time, show "Order Received" column(UID of mail if IMAP), and check which UIDs are changed from unread to read or vice versa, if possible, in addition to unread mail count, for ease of log analysis by developer, please.

Comment 19

[Dave Brooks]

(In reply to comment #18)
> Dave Brooks, thanks for getting IMAP log.
> If you test next time, show "Order Received" column(UID of mail if IMAP), and
> check which UIDs are changed from unread to read or vice versa, if possible, in
> addition to unread mail count, for ease of log analysis by developer, please.
 
The "Banking and IRD" folder has UIDs 1 to 13. The unread UIDs (on the server) are 12 and 13. Tb at times claimed that UID 12 was read. I don't have this information for the "Accutime Systems" folder -- will note it next time though.

Comment 20

[WADA:World Anti-bad-Duping Agency]

CC-ing to David. Do you have time to analyze IMAP log?

Comment 21

[WADA:World Anti-bad-Duping Agency]

"David" in my comment #20 == David:Bienvenu

Comment 22

[Dave Brooks]

(In reply to comment #19)
> (In reply to comment #18)
> > Dave Brooks, thanks for getting IMAP log.
> > If you test next time, show "Order Received" column(UID of mail if IMAP), and
> > check which UIDs are changed from unread to read or vice versa, if possible, in
> > addition to unread mail count, for ease of log analysis by developer, please.
> 
> The "Banking and IRD" folder has UIDs 1 to 13. The unread UIDs (on the server)
> are 12 and 13. Tb at times claimed that UID 12 was read. I don't have this
> information for the "Accutime Systems" folder -- will note it next time though.

Some more ideas and possible red herrings...

I've again set use_condstore, enabled logging, and run for a while.

The messages which appear as unread are always older ones, in fact all pre 2009. At the start of this year my IMAP server was changed from a very old version of Cyrus to Dovecot, with emails migrated using the cyrus2dovecot script. This means that whatever information Tb has about these messages was originally obtained from Cyrus which I'm guessing wasn't CONDSTORE aware.

Today, in all mailboxes with erroneous unread messages, one of those messages has a UID of 13. Is there some variable not being cleared/reset, resulting in a mailbox seeing information intended for another?? 

I could try deleting a folders msf file (as mentioned in comment 1 of bug 530551) and seeing what happens but would like a better understanding of what this will trigger beforehand. What is held in msf files? Do they keep MODSEQ numbers? Can someone point me to description of their layout??

Ta.

Comment 24

[David :Bienvenu]

Attachment: possible fix

I haven't reproduced this, but I suspect this patch will improve things. Previously, we were counting unread by iterating over the whole flag state, but with condstore, we often have partial flag states, in which case we should just use the UNSEEN count from the server.

Comment 25

[David :Bienvenu]

Comment on attachment 416867 [details] [diff] [review]
possible fix

fake server doesn't support condstore, and extending it to do that is a bit daunting.

Comment 26

[Dave Brooks]

(In reply to comment #24)
> Created an attachment (id=416867) [details]
> possible fix
> 
> I haven't reproduced this, but I suspect this patch will improve things.
> Previously, we were counting unread by iterating over the whole flag state, but
> with condstore, we often have partial flag states, in which case we should just
> use the UNSEEN count from the server.

Is this patch ensuring that the unread count in the list of folders matches the server? What I am seeing is Tb showing the actual message, in the folder's list of messages, being unread (in bold, a * in the 'Read' column and a blank 'Status' column). The unread count (in the list of folders) always matches the number of unread (bold, starred) messages.

Comment 28

[Sander Marechal]

Yes, I'm seeing the same thing as Dave in comment #26. It's not the unread count that is wrong. It's the unread messages themselves. The unread count on the left in the folder listing matches the number of unread messages on the right in the message listing. But the message listing is showing messages as unread that should be marked read (and are in fact marked read on the server).

PS: I've upgraded to TB 3.0 final today. I''ll see if it is still affected.

Comment 29

[Sander Marechal]

The problem still exists in TB 3.0 final.

Curiously I now have two folders that both show 35 unread e-mail while they both should have 0. I have moved messages into these two folders from my INBOX.

This may be a red herring though. This issue has also appeared in the past on folders that I do not move messages into (messages to those folders are delivered there directly by Dovecot's Sieve plugin).

Comment 30

[Sander Marechal]

Some more information:

Today I had again two folders with each having one message that was marked as unread while it should be read. I enabled the "order received" column and I noticed that they both had the same UUID: 196.

I went into a third folder that I knew had at least 196 messages in it and which did not have a problem. I enabled the Order Received column and looked up UUID 196. It was marked as read. Then I went back into the two folders that had a problem and the problem went away.

Comment 31

[Sander Marechal]

Haha, I can reproduce it! :-D

Prerequisites:

An IMAP account with multiple folders and new e-mail. Make sure some of the subfolders have new e-mail as well, as if it was delivered directly there by some server-side LDA like Sieve or Procmail.

Further more make sure that the messages in the various folders have overlapping UUIDs.

Steps:

1. Open Thunderbird
2. Click "Get Mail".
3. Go to a random folder
4. Click of a folder that has new e-mail (A) and *immediately* click on a different folder (B) that has no new e-mail. You need to be fast for this.

The last folder that you clicked (B) will now have several messages marked unread. If you check the UUID of these messages you will see that they are the same UUID as the new unread mail in folder A.

What seems to happen is that when you click folder A, TB fetches and calculates the UUIDs of the unread messages in folder A. By the time it is done with that, you have already moved on to folder B. The UUIDs that TB calculated for folder A are now applied to folder B.

Next, TB caches these unread UUIDs for folder B. When you mark the messages as read manually, TB will send out the proper IMAP commands to the IMAP server. But, the server sees these are already marked as read and does not update them. Thus the UUIDs do not change, thus TB does not drop it's cache.

I'm not sure that all of the above steps are required, but using this method with my Dovecot server (that supports CONDSTORE) I can reproduce the problem about 70%-80% of the time. It really depends on how fast I can click.

I hope this helps!

Comment 32

[Jeff Mitchell]

FWIW, I have experienced this bug with an Exchange 2007 IMAP server as well as with Dovecot. Granted, Exchange IMAP is horribly broken to begin with...

Comment 33

[Mark Banner (:standard8)]

Comment on attachment 416867 [details] [diff] [review]
possible fix

Yep, I think this would be good to get onto trunk for some testing.

I'd possibly consider for a point release, but considering we haven't got a clear test case, I think for .1 it won't be tested enough.

Comment 34

[David :Bienvenu]

fixed on trunk. FWIW, it's not a scary fix to me, since it only affects condstore servers, and what we were doing before was wrong...

Comment 35

[Mark Banner (:standard8)]

Comment on attachment 416867 [details] [diff] [review]
possible fix

I've had a report from a user that this definitely seems to improve the issue. As its a simple patch and affects condstore only, a=Standard8 for 3.0.1.

Comment 36

[David :Bienvenu]

fix landed for 3.01

Comment 37

[John Wilcock]

I'm still seeing spurious 'unread' messages and message counts with 3.01 beta (Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 ID:20100111101938) by clicking quickly from one folder to another as desdcribed in comment 31. 

The effect disappears if I set mail.server.default.use_condstore to false. 
This is with Dovecot 1.2.6, FWIW. 

I'm willing to do further tests, including server-side if necessary - but I'd need tips on where to start. For that matter, if devs want a temporary account on my IMAP server that can be arranged too.

Comment 38

[Ludovic Hirlimann [:Usul]]

(In reply to comment #37)
> I'm still seeing spurious 'unread' messages and message counts with 3.01 beta
> (Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.7) Gecko/20100111
> Thunderbird/3.0.1 ID:20100111101938) by clicking quickly from one folder to
> another as desdcribed in comment 31. 
> 
> The effect disappears if I set mail.server.default.use_condstore to false. 
> This is with Dovecot 1.2.6, FWIW. 
> 
> I'm willing to do further tests, including server-side if necessary - but I'd
> need tips on where to start. For that matter, if devs want a temporary account
> on my IMAP server that can be arranged too.

John can you raise a new issue for that ? and in that issue we'll need imap logs. 

Thanks for the account offer.

Comment 39

[Jay Levitt]

I'm seeing it with 3.0.1 release, and I might have been seeing it with 3.0 release - but I definitely did NOT see it on any 3.0 betas/RCs.  I'm using Dovecot as well. It's always the entire folder that appears unread (e.g. my Sent folder thinks it has 18335 unread messages); it happens with subfolders but not the INBOX itself. 

I just turned off condstore and restarted TB: so far, so good. I'm also happy to run tests but don't know where to start.

Comment 40

[Sander Marechal]

(In reply to comment #39)
> I'm seeing it with 3.0.1 release, and I might have been seeing it with 3.0
> release - but I definitely did NOT see it on any 3.0 betas/RCs.

Which betas and RCs did you use? I definitely had this problem in 3.0b4 and the RCs.

Comment 41

[tibey]

This bug is worse in 3.01 than in 3.0, why the status is "RESOLVED FIXED" ?

I had this problem in 3.0, got like 5 or 8 old email marked unread every morning in a couple of folders, but now in 3.01 wow... i got a ton of false unread messages and it keeps growing if i browse between them.

Strange thing, my co-worker who barely did'nt encounter this bug in 3.0 (same version as mine) now has the same problem in 3.01 just like Jay.

Comment 42

[WADA:World Anti-bad-Duping Agency]

Jay Levitt and tibey, never ignore "Target Milestone: Thunderbird 3.1a1", please.

Comment 43

[John Wilcock]

(In reply to comment #42)

What about "status-thunderbird3.0: .1-fixed"? I thought that meant a bug was (supposed to be) fixed in 3.0.1.

Comment 44

[Ludovic Hirlimann [:Usul]]

(In reply to comment #43)
> (In reply to comment #42)
> 
> What about "status-thunderbird3.0: .1-fixed"? I thought that meant a bug was
> (supposed to be) fixed in 3.0.1.

Indeed and it's not.

Comment 45

[WADA:World Anti-bad-Duping Agency]

Possibly a result that "review+/superreview+" & FIXED doesn't always mean "patch is landed on trunk" and "approval‑thunderbird3.0.1+" doesn't always mean "patch is landed on 1.9.1(or 1.9.2) branch". I'll check check-in history.

Comment 46

[Jay Levitt]

WADA, please note David Bienvenue's comment: "fix landed for 3.01".

Comment 47

[Jay Levitt]

(In reply to comment #40)
> (In reply to comment #39)
> > I'm seeing it with 3.0.1 release, and I might have been seeing it with 3.0
> > release - but I definitely did NOT see it on any 3.0 betas/RCs.
> 
> Which betas and RCs did you use? I definitely had this problem in 3.0b4 and the
> RCs.

Interesting.. I definitely did NOT have it in 3.0b3 or 3.0b4. I forget which RCs I used.

Comment 48

[David :Bienvenu]

There were/are a couple different problems going on - you could try a 3.01+ bug fix try server build here and see if it helps - http://s3.mozillamessaging.com/build/try-server/2010-01-20_15:[e-mail]-1264029848/[e-mail]

Comment 49

[Braden]

Also still seeing this (or something like it) in 3.0.1 on Mac OS X.

There are a couple of different observable issues here (which may or may not be traceable to the same underlying CONDSTORE problem(s)). Unread message counts for folders are consistently off. Selecting the folder updates the count; but upon restarting Thunderbird, the incorrect count will be shown again. I can't tell that the initial bogus count is related to messages that have become "unread"--but that's still happening, too. (It might be happening on smaller scale, though--hard to tell.)

Comment 50

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #46)
> WADA, please note David Bienvenue's comment: "fix landed for 3.01".

Sorry, I missed it.

As seen in bug 540554 comment #4, follow up works for remainig problem is in progress by bug 540554.
> Bug 540554 IMAP: In some folders a lot of mails is false marked as unread. (CONDSTORE is supportted by IMAP server)
And, there is known Bug 524902 too. 
> Bug 524902 Thunderbird sometimes fetches read/unread flags from the wrong IMAP folder
Watch these bugs, please.
If your remainig problem(even after fix of this bug) is different from these bugs, open separate bug with attaching sufficient data for diagnosis, please.

Comment 51

[Dennis]

Want to mention that this bug has caused me a lot of trouble. Thousands of messages were (apeareantly) randomly marked as unread. I'm using dovecot (latest version) as my mailserver
I tried installing 3.0.1 from scratch and still the problem occurred whenever I synced (from file menu).
The problem is not just the message count: the messages themselves were actually marked as unread (thanks god only locally, and not on the server)
Installing test build 2010-01-20_15:30 mentioned above solved the problem.
Please don't let this patch out of 3.0.2. Without it thunderbird is a bag of trouble for me. Shouldn't the status of this bug be changed?

Comment 52

[Mark Banner (:standard8)]

(In reply to comment #51)
> Shouldn't the status of this bug be changed?

No, you are probably seeing bug 540554, and I'm not sure if it was a regression from this bug or in fact one of the other bugs.

Comment 53

[David :Bienvenu]

It was not a regression from this bug - it was a regression from bug 524902

Comment 54

[Nikolay Shopik]

If it made sense I never seen problem when running tb3pre trunk and actually 3.0 was fine but 3.0.1 made this bug visible for me now.

Comment 55

[David :Bienvenu]

Nikolay, it should be fixed in 3.02pre nightly builds.

Comment 56

[WADA:World Anti-bad-Duping Agency]

If "EXPUNGE" is not notified via IDLE, and if Tb's CONDSTORE support is used, bug 1123094 can occur, so msgDBHdr of EXPUNGEd mail won't be removed by Tb, then not only "Unread count of Mbox" but also "Total number of mails in Mbox" becomes incorrect by that bug.
Setting dependency for futuare problem analysis of CONDSTORE relevant issues.

Comment 57

[WADA:World Anti-bad-Duping Agency]

Unread / Read in imap == Without \Seen flag / With \Seen flag of mail in Mbox held at imap server.
So, following bugs are perhaps involved in this bug for "Unread mail count".
(a) Bug 524902 / 541699 / 540554
      \Seen flag of wrong mail(mail in different folder of different server) is used => Ubread count is surely wrong
(b) Bug 693204
      IMAP server does not notify flag status change  via IDLE.
      Because command used for new mail check is "uid fetch NextUID:* Flags"(without CHNGEDSINCE, or wth CHANGEDSINCE is CONDSTORE is used),
      So, Tb can not know about flag state chaange until next full-resync by "SELECT / uid fetch 1:* Flags without CHANGEDSINCE" .
      Unread->Read==addition of \Seen flag, so "wrong Unread count" surely occurs if phenomenon of Bug 693204 occurs on \Seen flag.
      This is irrelevant to CONDSTORE is used or not.
(c) Bug 1123094   only when CONDSTORE is used
      If  \Deleted flag/EXPUNGE response is not passed from server(if cached connection for Mbox is stolen by other Mbox, this situation occurs)
      msgDBHdr of the deleted/expunged mail won't be removed.
      If the non-removed mail has Unread status, "wrong Unread mail count" surely happens.
(d) Bug 1124569   only when CONDSTORE is used
      If \Deleted flag is not notified from server
      (when IDLE is not used, this situation occurs. even when IDLE is used, many servers don't notify flaag state change via IDLE)
       "* n EXPUNGE response to noop upon next new mail check by Biff" is not correctly processed
      because Tb uses "SELECT / uid fetch 1:* flags (CHANGEDSINCE modseq)" so Tb doesn't know "message number" of already fetched mail. 
      Then msgDBHdr of the deleted/expunged mail won't be removed.
      If the non-removed mail has Unread status, "wrong Unread mail count" surely happens.

Because change by this bug is cause of bug 885220, and because problem of this bug is never "Unread count only issue" as known by above bugs, change by this bug should be backed out when above bugs will be resolved.

Comment 58

[WADA:World Anti-bad-Duping Agency]

Failed to linkify.
(a) Bug 524902 / Bug 541699 / Bug 540554

By the way, problem of this bug seems bug of (a). If so, patch by this bug(simply a workround on unread count only) can be backed out.