1791169 - All emails per folder is deleted and re-download repeatedly

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I use Thunderbird Daily, and perhaps starting from this week or perhaps around the last weekend, according to the Activity Manager, Daily started to delete all messages in every folder continuously and re-download all messages all messages of the folder repeatedly. I use IMAP accounts and the accounts have multiple folders and I deliver the incoming emails to every folder on the server-side. Therefore, I enable mail.server.default.check_all_folders_for_new pref (I'm not sure whether this causes this bug).

While the tasks run, I sometimes see the error dialog which notify me of "The folder '<folder name> on <email address>' cannot be compacted because another operation is in progress. Please try again later".

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Even after disabling mail.server.default.check_all_folders_for_new, this bug still occurs.

Comment 2

[Magnus Melin [:mkmelin]]

In that time range, bug 1776823 (and less likely bug 1787963).

Comment 3

[gene smith]

If this is due to bug 1776823 I'll need some more information from reporter.

How many imap accounts do you have set up? Approximately how many folders in each account?
How often do you have the accounts check for new mail? (Default is 10 minutes).
Do you use offline storage (mbox or maildir) for all folders or do you just keep the full messages on the server(s)?
You can also check for new mail in selected folder by right-clicking the folder under properties. Are any set like that?
Does setting this false fix the problem: mail.server.default.autosync_offline_stores ? To be sure it takes effect, restart TB after changing.

While the tasks run, I sometimes see the error dialog which notify me of "The folder '<folder name> on <email address>' cannot be compacted because another operation is in progress. Please try again later".

Are you manually requesting a compact or is this an automatic compact? Did you recently delete a lot of messages before this occurs?

Daily started to delete all messages in every folder continuously and re-download all messages all messages of the folder repeatedly.

Do you see activity in the status bar along the bottom about "downloading to folder X of Y messages"?

Even after disabling mail.server.default.check_all_folders_for_new, this bug still occurs.

For this too I would recommend a restart, just to be sure.

It may also be helpful to record and attach an imap log as described here: https://wiki.mozilla.org/MailNews:Logging
Need to include the autosync logging so set environment var MOZ_LOG to IMAP:5,timestamp,sync,IMAPAutoSync:5

Comment 4

[gene smith]

I'm not yet seeing any problems running today's TB daily 106.0a1 (2022-09-17) (64-bit) with this command line:
MOZ_LOG=IMAP:3,timestamp,sync,IMAPAutoSync:5 MOZ_LOG_FILE=~/tblog ~/Downloads/thunderbird/thunderbird --allow-downgrade -p

Comment 5

[gene smith]

After I moved two messages from Inbox to another folder on the same imap account, that folder went blank on the screen. Looking at imap log, it appeared that all messages were still there. When I moved to several other folders to force a disconnect from the problem folder, the messages re-downloaded into the folder. I'm not sure what is causing this. I'll look closer at it tomorrow since it appears that I can probably duplicate it.

Reporter Masayuki, if this seems similar to what you are seeing you can skip producing the imap log that I requested. I suspect that since new messages are delivered to almost all your folders at various times by server-side filters, it will appear to affect almost all folders for you as you reported.

Comment 6

[gene smith]

Magnus, I'm not seeing the problem when I take out my autosync changes at bug 1776823. Not sure why I didn't see this problem when I tested before. So maybe better to back out the changes from daily and I'll try some more to determine what is causing the problem.

Comment 7

[Magnus Melin [:mkmelin]]

Ok, let's back out 9d358a4c4bb5

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d55a77dd0027
Backed out changeset 9d358a4c4bb5 for causing bug 1776823. rs=backout

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thanks, it seems that the backing out fixed the reported issue in my environment too.