Duplicate messages appearing in list, and some messages not appearing (IMAP)

RESOLVED FIXED in Thunderbird 3.0b3

Status

MailNews Core
Database
P2
critical
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: Marcus, Assigned: Bienvenu)

Tracking

({dataloss, qawanted})

Trunk
Thunderbird 3.0b3
dataloss, qawanted
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 +
wanted-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Thunderbird 2.0.0.9

This has happened multiple times now:  The same message appears twice in my inbox (inbox on IMAP server, not local inbox).  Also some messages don't appear in my inbox, but if I do a Search, the Search does find the message and says it is in the inbox but then if I go to the inbox it definitely does not appear in the list.

I know this is a bug because if I use "Rebuild Index" on the inbox folder, the duplicates disappear, and the messages failing to appear then appear.  "Rebuild Index" fixes the problem... until it happens again some time later.

I am using IMAP, and I am keeping the messages on the IMAP server so that I can access them from 2 different computers (both using Thunderbird).   I have the Offline Messages option enabled for all folders.   This combination of IMAP and Offline Messages is probably where the bug is -- I imagine this bug doesn't occur if using POP.


Reproducible: Sometimes

Steps to Reproduce:
To reproduce this bug, I expect that you must be doing what I am:  using IMAP and leaving the messages on the server (NOT downloading them to your local inbox folder).  i.e. the bug occurs with the inbox folder on the IMAP server, and probably not with the local inbox folder.   Also, I have the Offline Messages thing enabled for all folders, that is probably also required to reproduce this bug.
Actual Results:  
Messages appearing twice in the list in inbox, and some messages not appearing at all but discoverable via Search.


Using "Rebuild Index" solves the problem until it happens again some time later.
(Reporter)

Updated

10 years ago
Version: unspecified → 2.0
Do you see the problem if you don't have "Offline Message" option enabled?
Did this NOT happen in version 1.5, using the exact same (unchanged) account settings?
(Reporter)

Comment 2

10 years ago
I am new to Thunderbird.  2.0.0.9 is the first version I have ever used.  So I don't know if the bug exists in the 1.5 version.

I don't know if the bug still occurs when the "Offline Messages" option is disabled.  I will try disabling it and see if it occurs again.

Another thought, the bug might possibly be related to the deleting of messages.  I have Thunderbird set to move deleted to the trash folder.

I also have a number of Search Folders created.  I don't know if that is relevant.
(Reporter)

Comment 3

10 years ago
Argh the problem happened again.  I was looking at the list of folders and for the Inbox (on the IMAP server) it said 5 unread messages, but I scrolled up and down the list of messages in the inbox several times but could find only 2 unread messages.

So I clicked "Rebuild Index" and then the other 3 unread messages re-appeared.  So the count of unread messages was correct, but 3 of the 5 unread messages were not appearing in the list!!!  (until I clicked Rebuild)
If mail number is changed on IMAP server, phenomenon you described can occur.
 1. mail-1 == N1, and fetched
 2. mail-1 => N2 (changed), new mail-2 == N1(reused)
 => N2(mail-1) is fetched, then duplicated mail-1 for N1 and N2
 => new mail-2(==N1) is not newly fetched, because N1 is already fetched
 => Search can find mail-2, because searched by IMAP SEARCH command at server
 => If rebuild-index is executed, mail-1(N2) and mail-2(N1) is re-fetched

Show "Order Received" column and check number assigned to mails.
When duplicated mail is observed, different number in "Order Received" column? Or same number?

Updated

10 years ago
Assignee: nobody → bugmil.ebirol

Comment 5

9 years ago
I have the same problem on a setup similar to Marcus'.

The duplicated mails have the same number in the "Order Received" column.

I also have another symptom. Sometimes when deleting or moving messages, an empty line is shown in the mails box, which cannot be deleted, (But rebuild index removes it) and some messages are hidden. If some of them are new the folder is marked as having new messages, but they are not shown in the list.
(Reporter)

Comment 6

9 years ago
I too have seen the empty/blank line that Jacob describes, that is removed when "Rebuild Index" is used.  And yes I also have seen the folder being marked as having unread messages, but I cannot see the unread messages until I use "Rebuild Index".

Comment 7

9 years ago
confirming this bug on 2.0.0.14 on Linux (Ubuntu 8.04). Same thing - IMAP folder, some messages duplicated, others "hidden" - order received is the same on the two duplicates. I have also experienced the same blank lines when deleting messages.

Also had the inbox showing that there was 1 new message in the folder pane on the side, but not in the messages pane (the new message was actually there when accessing the same account using a webmail client, but I could not reach this message in thunderbird.

if it sheds any light, the "hidden" new message that was new but could not be navigated to in the inbox did go straight to its appropriate saved-search folder, and did have the right title and body. Viewing it in that folder remoed the (1) new message status in of the inbox in the folder pane (because this WAS the new message) but the message still could not be located in the inbox (could only navigate to it using a saved-search folder)

Comment 8

9 years ago
forgot to confirm that "Rebuild Index" fixes the symptom and each message has a unique "Order received" number. It does not fix the issue, as these symptoms return again (though it doesn't happen every time, thus it's difficult to isolate an easily reproducible example)
(In reply to comment #7)
When "search target folder" of a "saved search folder" is IMAP folder, option of "Seacrh Online" exists(if checked, searched by IMAP SEARCH command, else searched locally). Which option do you use? 
"Offline use" option is on for the IMAP Inbox?
When "dup'ed message & hidden message" happens on Inbox, "click other folder, then click the Inbox again" will alter situation?

If "dup'ed message & hidden message" happens on Inbox again, do next, please.
1. Keep back up of INBOX.msf under ImapMail directory under Mail directory
2. Re-build Index
3. Keep back up of refreshed INBOX.msf
4. Check content of (1) by text editor
Dup'ed data for dup'ed mail in (1)? Data for the hidden mail is found in (1)?

Comment 10

9 years ago
> When "search target folder" of a "saved search folder" is IMAP folder, option
> of "Seacrh Online" exists(if checked, searched by IMAP SEARCH command, else
> searched locally). Which option do you use? 

This particular filter was searched locally.

> "Offline use" option is on for the IMAP Inbox?

Yes. "Offline use" is on. I did do a File -> Offline -> Download/Sync Now (without actually going offline) earlier today.

> When "dup'ed message & hidden message" happens on Inbox, "click other folder,
> then click the Inbox again" will alter situation?

No, I did this several times and the dup'ed and hidden messages still stayed dup'ed and hidden, respectively.

I'll keep a lookout and do the thing you suggest the next time this happens, thanks.

(In reply to comment #10)
> This particular filter was searched locally.
> Yes. "Offline use" is on. I did do a File -> Offline -> Download/Sync Now
> (without actually going offline) earlier today.

Locally saved mail data can have relation to problem. Please keep back up of file of INBOX(no file extension. downloaded mail data when "Download/Sync Now". "saved search folder" possibly searches this file in your case.) in addition to INBOX.msf(mail DB) when problem occurs again.
To Marcus(bug opener), Jacob Kjeldahl, Paul Ivanov:  

Does your IMAP server support IDLE command?
Do you enable "Use IDLE support if the server supports IDLE command" option?
What value do you set in "check for new message every NN minutes"?

Comment 13

9 years ago
> Does your IMAP server support IDLE command?

I tried looking around but could not figure this out from the docs (calmail.berkeley.edu)

> Do you enable "Use IDLE support if the server supports IDLE command" option?

Yes

> What value do you set in "check for new message every NN minutes"?
every 10 minutes
(In reply to comment #13)
> > Does your IMAP server support IDLE command?
> I tried looking around but could not figure this out from the docs (calmail.berkeley.edu)

Get IMAP protocol log(NSPR log) for "Start TB, click the IMAP account, terminate Tb". If log for IDLE is seen, it's the evidence that your IMAP sever supports IDLE.
(In reply to comment #13)
> > What value do you set in "check for new message every NN minutes"?
> every 10 minutes

Silly question to avoid misleading to wrong problem analysis steps.
  Is option of "check for new message every 10 minutes" enabled?

Bug 193325 is a report of "many duplicated mails" upon IMAP with slow dial up connection, when "check for new message every *1* minutes"(too short interval for slow connection).
In Screen shot attached to Bug 193325 Comment #11, you can see phenomenon of "almost all mails are dup'ed".
Very old Bug 219251 seems to be similar issue to Bug 193325.

Bug 193325 sounds to be following issue;
 1. Mail download process is invoked by "check for new message every" setting,
    and FETCH is requested and FETCH command itself is probably completed,
    but "set status as 'not new mail'" is not done yet.
 2. Before completion of all processes of step 1, second download process is
    invoked by "check for new message every *1* minutes" setting.
    Then FETCH command for the mail is requested again, and duplicate entry for
    same mail is produced in mail DB.

Bug 379039 seems to be "hidden mail" case upon similar situation.
> Bug 379039 Some random messages not showing in Inbox IMAP folder.

Scenario like following is suspected when this bug.
  0. High-watermark==N. Largest downloaded UID==P
  1. New mail(s) arrive at IMAP server
  2. Download processes by IDLE is invoked,
     but all processes for download is not completed yet.
     2-1. FETCH for mail(UID=Q, Q>=P+1) (Save as <N+1>th mail).
          "\Seen is set by FETCH or not" depends on environment.
     2-2. Set High-watermark to <N+1>
     2-3. "STATUS flag \Seen" if required
     2-4. Repeat 2-1 to 2-3 for all new mails, increasing UID, High-watermark
 (2-X. New mail(s) arrive at IMAP server additionnaly)
  3. Download process by "check for new message every 10 minutes" is invoked,
     before completion of download by IDLE.
     And execute same actions as step 2. to download mails,
     based on incomplete status of step 2 due to the inturruption.
  4. Inturrpted step 2. is re-started, and remaing actions are executed
     based on mixture of status when step 2 was invoked and status when step 3
     was completed.

  ==>  Number of dup'ed mails & hidden mails depends on ;
       - Number of new mails arrives at step 1 (and 2-X).
       - Whether \Seen is set on FETCH or not
       - At where actions of step 2. is interrupted by invoking of 3.

Comment 16

9 years ago
(In reply to comment #14)
> (In reply to comment #13)
> > > Does your IMAP server support IDLE command?
> Get IMAP protocol log(NSPR log) for "Start TB, click the IMAP account,
> terminate Tb". If log for IDLE is seen, it's the evidence that your IMAP sever
> supports IDLE.
> 
Server supports IDLE.

CreateNewLineFromSocket:  CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID ACL RIGHTS=kxte QUOTA NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED

(In reply to comment #15)
> (In reply to comment #13)
> > > What value do you set in "check for new message every NN minutes"?
> > every 10 minutes
> 
> Silly question to avoid misleading to wrong problem analysis steps.
>   Is option of "check for new message every 10 minutes" enabled?

Yep, it is enabled.

> Bug 193325 is a report of "many duplicated mails" upon IMAP with slow dial up
> connection, when "check for new message every *1* minutes"(too short interval
> for slow connection).

Could intermittent wifi connectivity be the culprit? Connection is fast when enabled, but when there is no connection thunderbird is still left in "online" mode (and gives errors about not being able to find mail server, etc)

> 
> Bug 379039 seems to be "hidden mail" case upon similar situation.
> > Bug 379039 Some random messages not showing in Inbox IMAP folder.

Yes, certainly looks very similar (if not duplicate) to this situation.

> Scenario like following is suspected when this bug.
sorry, i did not follow the rest of this, but hopefully someone else will.
(In reply to comment #16)
> > Bug 193325 is a report of "many duplicated mails" (snip)
> Could intermittent wifi connectivity be the culprit?

I don't think so. I think culprit is "execution of timer-pop download before completion of previous download", although connection error can produce duplicate mail phenomenon upon any of POP3, IMAP, and SMTP. I saw a bug which explicitly refers to "download before completion of previous download" in bugs for "duplicate mail problem", but I couldn't recall bug number. (too many bugs for dup'ed mails)
Adding IMAP in bug summary, for ease of search.
Summary: Duplicate messages appearing in list, and some messages not appearing → Duplicate messages appearing in list, and some messages not appearing (IMAP)

Updated

9 years ago
Flags: wanted-thunderbird3.0a2+
Flags: wanted-thunderbird3+
Confirming based on comments as well as flags being granted.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 20

9 years ago
Created attachment 324699 [details]
INBOX and INBOX.msf before and after index rebuild

contains "bug414723" folder with INBOX and INBOX.msf in "beforerebuild" and "afterrebuild" subfolders. Hope I cleaned out Also contains README which contains the following:

Here is an example (before and after rebuilding the index) of bug 41423.

The message from ldoe@university.edu with Subject: "Cleaning of Staff Lounge Frig 6/13)" was duplicated (listed twice) in the Inbox, and the message from <team@votenader.org>  Subject: "Nader and the NBA" was hidden (not listed at all).

Note: there were no other messages from either of these two addresses in the Inbox at the time.

In particular: 
the message from <ldoe@university.edu> Subject: "Metal table in breezeway" and 
the message from <team@votenader.org> Subject: "Foregone Conclusion"

along with other emails from other addresses were all already moved or deleted from the Inbox (and were no longer listed there)
(In reply to comment #20)
> INBOX and INBOX.msf before and after index rebuild

> Content of bug414723\beforerebuild\INBOX.msf
> Line-63: (57F=20080611164056.A70C724831@mailman03.highwire.org)(582=7634)(5A4
> Line-64:    =2ef31)(599=71d7)(59A=4b0)(59C=2bdf4)(585
> Line-65:    ="Jott Networks" <notify@jott.com>)(586
> Line-66:    =Jott June Newsletter - Jott Feeds, Great Press, and more)(587
> Line-67:    =2040987648.32050@jott.com)(589=UTF-8)(58A=22db)(59B=2bdd4)(59E=22c3)
> Line-68:  (59F=6b)(59D=80)(5A1=2e0b)(58E=Linda doe <ldoe@university.edu>)
> Line-69:  (58F=opt-everyone@lists.university.edu)(590
> Line-70:    =Cleaning of Staff Lounge Frig 6/13)(591
> Line-71:    =6.1.1.1.2.20080611105756.01d83820@mail.university.edu)(593=ea5)
> Line-72:  (5A0=2e097)(5A2=e9a)(5A3=5e)(5B0=36128)(5A8
> Line-73:    =The Nader Team  <team@votenader.org>)(5A9=Nader and the NBA)(5AA
> Line-74:    =198C282645745C380C2EC2FEC817653FAB23253098D5DA7E@contact.votenader.org)
> Line-75:  (5AC=2740)(5AF=36108)(5B1=26e2)(5B2=b1)>

(5A1=2e0b) in Line-68 is culprit?

"xyz" in "(xyz=pqrstu)" looks to be sequence number in hexa-decimal.
"(5A0=2e097)(5A2=e9a)(5A3=5e)" looks to be data for (5A8=The Nader Team  <team@votenader.org>), which is the hidden/last mail. 
And, (5A1=2e0b) in Line-68 looks to be data for (58E=Linda doe <ldoe@university.edu>), which is duped mail.
If sequence number, (5A4=2ef31) in Line-63/Line-64 for (585="Jott Networks" <notify@jott.com>) may be a culprit.
Changing to Core/Networking:IMAP.
Component: General → Networking: IMAP
Product: Thunderbird → Core
Version: 2.0 → 1.8 Branch
... and proper QA.
QA Contact: general → networking.imap

Comment 25

9 years ago
I have been able to capture another occurrence of this bug. Let me know if I should post another pair of INBOX+INBOX.msf before and after the index rebuild (and if I should include a screenshot of before and after).

This time a new message was hidden (as in comment #3 and comment #7). Inbox claimed to have 1 new message, but no new messages were showing inside of it and there was one duplicate message. Rebuilding the index got rid of the duplicate and revealed the hidden message.

Not sure if it matters but both the hidden and the duplicate message are part of separate search folders. In comment #20, the duplicate message was part of a search folder.

Updated

9 years ago
Flags: wanted-thunderbird3.0a2+
Priority: -- → P2
This is effectively dataloss, since if the user doesn't know to rebuild their folder, they've essentially lost these messages forever.  Upgrading severity and adding dataloss keyword.

Adding qawanted in the hopes that we can get reproducible test-case on trunk.  If such a thing does happen, please nominate to block Thunderbird 3.
Severity: major → critical
Keywords: dataloss, qawanted
Target Milestone: --- → mozilla1.9.1
Given that the failure mode is really bad here, and since there's forensic data here, I think we have to block on at least looking at that forensic data.
Flags: blocking-thunderbird3+
Whiteboard: [needs dev investigation]
(Assignee)

Comment 28

9 years ago
taking - I'm not sure how useful the .msf files are here, since the important question is "how did the bad data get into the .msf file?". For that, a protocol log is probably more useful but I'm sure this bug is really hard to catch in the act. I'll poke around the .msf files, though. Logically, we must be writing the same hdr info for two different uids into the .msf file, which probably means that we must be getting confused about what the current msg uid is when parsing headers.
Assignee: bugmil.ebirol → bienvenu
Version: 1.8 Branch → Trunk
xref bug 449366, bug 379039.
bug 460092?
Product: Core → MailNews Core
(Assignee)

Comment 30

9 years ago
Created attachment 359669 [details] [diff] [review]
try to catch this in the act, and potential fix

I just had this happen to me, so I dug around in the debugger and the code to try to see what was going on. I found that we had a thread with the wrong message in it, i.e., the msg thought its thread id was X, but it was in the thread with id X -1. I've added some assertions and warnings to try to catch this in the act. In the process, I found situations where we were creating new thread objects in the mork db, but getting back existing thread objects with stale data in them, so I added some code to make sure we clear out all the columns for the thread row and the meta row when creating new threads. I think that situation arose when we deleted a message and undid the delete, though I'm not positive about it. I'm going to run with this and see if it helps.

For the record, the imap log for the message that had the issue showed us fetching the headers, then the preview text, then I think the offline store peek, and then the message body for display (I might have that backwards). The urls got queued up one after the other, which may have had something to do with the problem.
(In reply to comment #30)
> i.e., the msg thought its thread id was X, but it was in the thread with id X -1.

It sounds for me that phenomenon/problem is an variation of "thread unsafe IMAP code" issues. Is it right?
(Assignee)

Comment 32

9 years ago
no, I don't think so - the imap code only touches the db on the single ui thread, and only ever runs a single url against a folder at one time.
(Assignee)

Comment 33

9 years ago
Created attachment 359867 [details] [diff] [review]
try to cleanup confused threads

this is an attempt to fix the confused threads - I'll run with this for a while and then ask for review. I don't really have a test case for this...
(Assignee)

Comment 34

9 years ago
Comment on attachment 359669 [details] [diff] [review]
try to catch this in the act, and potential fix

this part was checked in in an other bug:

+  {
     (*pnewThread)->SetThreadKey(threadId);
+     m_cachedThread = *pnewThread;
+     m_cachedThreadId = threadId;
+  }


the rest is still a candidate for landing.
Paul and Marcus can you reproduce this bug easily ? If so would you be willing to test a special build and see if the problems persist with that specific build ?
Target Milestone: mozilla1.9.1 → Thunderbird 3.0rc1
(Assignee)

Comment 36

8 years ago
Moving to b4 - I'd really like to figure this out for b3, though.
Assignee: bienvenu → nobody
Status: NEW → ASSIGNED
Component: Networking: IMAP → Database
OS: Windows XP → All
QA Contact: networking.imap → database
Hardware: x86 → All
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.0b4
(Assignee)

Updated

8 years ago
Assignee: nobody → bienvenu
(Assignee)

Comment 37

8 years ago
Created attachment 380182 [details] [diff] [review]
cumulative fix

I'm going to run with this a while - it does fix the duplicates for me (though you may have to load the folder twice to see the fix, depending on where we were in the view creating process), but I'm going to try to see why we get into this situation in the first place.
Attachment #359669 - Attachment is obsolete: true
Attachment #359867 - Attachment is obsolete: true
(Assignee)

Updated

8 years ago
Attachment #380182 - Flags: superreview?(neil)
Attachment #380182 - Flags: review?(bugzilla)
(Assignee)

Comment 38

8 years ago
Comment on attachment 380182 [details] [diff] [review]
cumulative fix

this patch helps a lot with the duplicate/missing messages, which I've been seeing semi-regularly with imap.

The first part is if we're creating a new thread, but find an existing threadRow w/ that id, make sure we clear out its contents so we don't have any cruft left over. 

The second part is to try to repair msgs that have one thread id but are actually in a different thread.

Updated

8 years ago
Attachment #380182 - Flags: superreview?(neil) → superreview+
(Assignee)

Updated

8 years ago
Duplicate of this bug: 475533
Duplicate of this bug: 457139
To David Bienvenu:

This kind of issue is very hard to resolve, because user including me can't reproduce problem by himeself, and because no developer usually can see the problem(you are an  very rare exception). Do you have any plan to enhance assertion or new NSPR logging for catching cause of this bug's problem?
(In my past work for problem analysis of troubles at customer of a computer-hard & OS/middle-ware/application-software vendor, trap code is used for problem analysis in many cases.)
(Assignee)

Comment 42

8 years ago
I've tried to add assertions to catch this bug happening, but it's been very elusive.
Attachment #380182 - Flags: review?(bugzilla) → review+
(Assignee)

Comment 43

8 years ago
fix checked in - I changed an NS_ERROR to an NS_WARNING, first, however.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [needs dev investigation]

Comment 44

8 years ago
(In reply to comment #43)
> fix checked in - I changed an NS_ERROR to an NS_WARNING, first, however.

I can still duplicate this problem at will.

I have an IMAP account that has several search folders (bad tripwire reports, good tripwire reports).  As I mark the messages read in the saved search folders, then move to the real folder, the logwatch message is always gone but there is still a (1) next to the folder indicating there's an unread message.

This occurs every time -- using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090605 Lightning/1.0pre Shredder/3.0b3pre, on an IMAP server that supports IDLE:  

* CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH

If there's anything more I can do to help for this one, I'd be happy to.
(Assignee)

Comment 45

8 years ago
Ray, once you're in this state, if you do a quick search using the widget in the upper right hand corner of the window, does it turn up the missing message?

Are these saved searches have just the inbox as the scope? I'm not convinced you're seeing the same problem. I know there are sometimes unrelated problems adjusting the counts on folders when messages are changed from different folders.

Comment 46

8 years ago
(In reply to comment #45)
> Ray, once you're in this state, if you do a quick search using the widget in
> the upper right hand corner of the window, does it turn up the missing
> message?

Yes, it sure does!  And when clearing the search, the message disappears.  The message also reappears if I rebuild the folder index.  Another interesting note is it's /always/ the logwatch report.

> Are these saved searches have just the inbox as the scope? 

No.  I have a "Servers" folder with 35 folders in that.  The Saved searches start at "Servers" and recursively search.

> I'm not convinced
> you're seeing the same problem. I know there are sometimes unrelated problems
> adjusting the counts on folders when messages are changed from different
> folders.
(Assignee)

Comment 47

8 years ago
Ray, can you email me the .msf file of the real folder once you're in the state where quick search shows you the message but clearing the search does not, along with the subject of the message? Does the logwatch report always have the same subject and/or message-id?

Comment 48

8 years ago
(In reply to comment #47)
> Ray, can you email me the .msf file of the real folder once you're in the state
> where quick search shows you the message but clearing the search does not,
> along with the subject of the message? 

Mail is inbound, along with a couple of PNG's showing the issue.

More information:  After I search and find the message, clearing the search hides the message again, but if I change folders and come back, the message is now visible in the folder.

>Does the logwatch report always have the same subject and/or message-id?

No.  The subject is identical, but the message id's are different.
(Assignee)

Comment 49

8 years ago
the patch I checked in for this bug should make it so clicking away from the folder and back, even w/o doing the quick search, should repair the threading such that the missing message re-appears. Are you seeing that?

Thx for the .msf files - I'll look at them, and see if I can reproduce the problem with the saved searches. Now that I think of it, I was seeing this problem more on a machine where I read my incoming mail in a saved search.

Comment 50

8 years ago
(In reply to comment #49)
> the patch I checked in for this bug should make it so clicking away from the
> folder and back, even w/o doing the quick search, should repair the threading
> such that the missing message re-appears. Are you seeing that?

Yes, when go back and forth twice.

Steps to get message to appear sans searching:

Click on folder -- no message
Click on different folder, click back on folder -- still no message
Click on different folder, click back on folder -- message appears.

Getting closer!

Thanks!

Comment 51

8 years ago
And I can still reproduce it (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090605 Lightning/1.0pre Shredder/3.0b3pre)
(Assignee)

Comment 52

8 years ago
Omar, does the problem fix itself when you leave the folder and come back?

I was only able to repair the problem once I had a .msf file w/ the problem. I haven't been recreate the original mis-threading though I'm trying with the steps Ray gave.

Comment 53

8 years ago
I usually use All Folders view and I have to switch to Smart Folders view and click on different folder to fix it. In the meantime Tb crashes (bug 492571)
Target Milestone: Thunderbird 3.0b4 → Thunderbird 3.0b3
I still see duplicate messages on last night's Shredder (2009-06-11 3.0b3pre). It only happens in my Inbox for one of my accounts. This Inbox is the only folder for which I have saved searches defined. The searches are stored in the Local Folders part of the account tree. Visiting those searches gives the correct result and, when I return to the INBOX, the problem is no longer seen. Rebuilding the index in the INBOX causes it to reappear - i.e. the index rebuilding process gives an incorrect result. I have not yet determined whether the problem only occurs for messages which are caught by the terms of one or more of the searches, but that may well be so.

Do let me know if I should file a new bug.

Gerv

Updated

8 years ago
Depends on: 501392
Blocks: 402017
Blocks: 454611
Duplicate of this bug: 383210
Blocks: 569065

Updated

7 years ago
No longer blocks: 569065
You need to log in before you can comment on or make changes to this bug.