1493480 - IDLE response sometimes ignored if autosync is enabled

Status: RESOLVED DUPLICATE of bug 1708981

(MailNews Core :: Networking: IMAP, enhancement)

Description

[gene smith]

This problem was first noted in Bug 1428097 comment 72. With an imap account having 22 selectable mailboxes (folders) and 5 (default) cached connections and idle enabled, if tb is shutdown with a not Inbox folder selected, e.g., 555, on restart initially 1 or two connection are created, with one connection selected on folder 555. After idle is enabled on the connection for 555, idle is interrupted (with DONE) and a STATUS command is run for a non-selected folder then idle is re-enabled. Then immediately 555's idle is interrupted again with DONE and another non-selected folder is checked for STATUS and IDLE is re-enabled. This occurs for 4 non-selected folders and, as it should, idle remains enabled for 555. For reference, the *last* non-selected folder checked for STATUS is called nf-bear.

Then on another client a new message is added to 555. This causes the connection on TB that is idling folder 555 to immediately response with "* 27 EXISTS" as it should. The code in tb that handles the idle response runs as it should and records the new message count, 27. However, instead of calling the code that should now update the contents of 555, a url containing the folder name nf-bear is processed and no update occurs for folder 555. Instead, the update occurs for folder nf-bear!

If nf-bear is not yet selected in a connection, a new connection is established and nf-bear is selected and goes into idle mode. If nf-bear is already selected in a connection, the idle response on 555 causes nf-bear's IDLE to be interrupted (with DONE) and nf-bear folder is updated (but nothing to update) and then it returns to idle. In either case, 555 is *not* updated even though it received the meaningful idle response (telling it there is a new message).

After the wrong folder responds to 555's idle response, 555 no longer responds to additional idle events (e.g., another new message added by other client). I think this is because it never receives a DONE command.

If instead of just staying on 555 when tb starts, if several other folders are selected and then you select 555 again, this usually enables 555 to completely respond to and update itself when an idle response occurs and another folder does not incorrectly respond and update.

I have been unable to determine why this problem occurs. I think the problem may originate in the high level code that selects which non-selected folders have STATUS checked. The choice seems to be random, but once determined it seems to repeat on subsequent tb start-ups as long a the same folder, e.g., 555, remains selected. The last STATUS url containing nf-bear seems to remain in effect and cause nf-bear to update instead of 555.

Comment 1

[gene smith]

Attachment: idle-response-triggers-different-connection.diff

Not a patch. This just shows and saves the printf's that I added to test and try to debug this. (There are a few other CONDSTORE related changes in here too but they aren't related to this bug.)

Comment 2

[gene smith]

The problem goes away if I disable autosync, specifically mail.server.default.autosync_offline_stores = false (default is true).
The status check of a (random?) set of folders while selected on a specific folder (555 in my example above) does not occur with autosync disabled and the idle response for folder 555 causes 555 to update properly. The correct url that commands a "select" is used that contains 555 and not the last folder of the status check set (nf-bear in my example above).

Comment 3

[Wayne Mery (:wsmwk)]

FWIW, our other currently open IDLE bug reports https://mzl.la/2pi7Njr

Comment 4

[gene smith]

This is caused by the "folder sink" for a non-selected folder being used to respond to IDLE. Sounds exactly the same as bug 1708981 which is in review process and should be fixed soon.