584327 - test_localToImapFilterQuarantine.js intermittent timeout on Linux | test failed (with xpcshell return code: 0)

Status: VERIFIED FIXED

(MailNews Core :: Filters, defect)

Description

[Mark Banner (:standard8)]

Attachment: Failing test

After we landed bug 580108, test_localToImapFilterQuarantine.js is permanently failing on Linux.

This is strange, because a test shouldn't be relying on a server timeout to pass, or certainly not without explicit confirmation. Also, it is only happening on Linux (both 32 and 64 bit).

I've disabled the test on Linux for now, but we should try and fix the issue with the test.

I'll attach a couple of log files (with just imap logging on), one before bug 580108, and one after.

Comment 1

[Mark Banner (:standard8)]

Attachment: "pass" log

The "pass" case is definitely waiting for a timeout - I discovered that when generating the log.

Comment 2

[David :Bienvenu]

can you tell where in the log it's waiting for the timeout? And which server is timing out (the pop3 one or the imap one?)

The good news is that fixing this will speed up the linux tests by three minutes :-)

Comment 3

[David :Bienvenu]

actually, adding timestamp to the imap log would be helpful, as well as turning on the pop3 logging...

Comment 4

[Serge Gautherie (:sgautherie)]

http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1284963793.1284968586.11746.gz&fulltext=1
Linux x86-64 comm-central check on 2010/09/19 23:23:13

Same log as in bug 596184 comment 0:
It looks like
http://hg.mozilla.org/comm-central/rev/f28c929a61a1
"Shorten the asyncTestUtils timeout to just under 300 seconds ..."
made no difference.

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1284963793.1284968586.11746.gz&fulltext=1
> Linux x86-64 comm-central check on 2010/09/19 23:23:13

No need to comment every time thanks, I know this is a very frequent failure at the moment and its on my things of to look at.

> Same log as in bug 596184 comment 0:

(hence the dependency)

Comment 6

[Bruno 'Aqualon' Escherl]

Attachment: Log of failure with NSPR_LOG_MODULES=imap:5,pop3:5,smtp:5,MSGDB:5,timestamp

Got this last night at the 29. run of the mailnews xpcshell-tests on Linux. So still there but quite rare.

Comment 7

[Mark Banner (:standard8)]

Attachment: Possible fix [Checked in: Comment 7]

I've just landed this to try and fix the issue (as the Thunderbird Linux tinderboxes were pretty much permanently orange due to this and other errors).

The issue and solution goes something like this:

1) Mail is downloaded from the pop3 server.
2) That mail is filtered across to the imap server.
3) We then update the folder so that we can check its contents.

However, there is no notification for the APPEND that the filtering is doing in step 2. So sometimes (as in the log attached to this bug), that APPEND fails.

At this point, UpdateFolderWithListener returns silently and OnStopRunningURL never gets called. We then get stuck ;-)

So I've changed the test to re-run UpdateFolderWithListener occasionally so that we can ensure we get the listener.

The test worked fine locally for me with the changes - I'd previously been able to replicate it by putting my machine under a little bit of load.

Given the tree is so bad wrt orange at the moment, I checked it in and hopefully this will green it up a bit:

http://hg.mozilla.org/comm-central/rev/b07527a173c0

Comment 8

[Mark Banner (:standard8)]

I've not seen this since I landed the patch, and it was pretty frequent on Linux before I did so. Therefore tentatively marking as fixed.

Comment 9

[Kent James (:rkent)]

Looking at the patch, would it be fair to say that the test has uncovered a core flaw (that UpdateFolderWithListener does not properly indicate when it is done)?

If so, it seems odd to me to "fix" the test by working around the core flaw, rather than fixing the core flaw. The point of tests after all is to test, not to just run without failure (unlike an extension, where I do this kind of workaround all of the time).

With our current testing platform, there is no real support for tests that have known issues that need fixing, so I guess a workaround is the only alternative. But me thinks you should at least spin off a core bug, pointing to this one, that requests that the core issue be fixed.

Comment 10

[Serge Gautherie (:sgautherie)]

V.Fixed, confirming comment 8.

Though I had the same thoughts as in comment 9...

Comment 11

[Mark Banner (:standard8)]

Thanks fro filing the bug - I was thinking about filing it at the time, but forgot.