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

VERIFIED FIXED in Thunderbird 3.3a1

Status

MailNews Core
Filters
VERIFIED FIXED
8 years ago
5 years ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

(Blocks: 1 bug, {intermittent-failure, regression})

Trunk
Thunderbird 3.3a1
intermittent-failure, regression
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Assignee)

Description

8 years ago
Created attachment 462741 [details]
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.
(Assignee)

Comment 1

8 years ago
Created attachment 462742 [details]
"pass" log

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

Comment 2

8 years ago
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

8 years ago
actually, adding timestamp to the imap log would be helpful, as well as turning on the pop3 logging...
(Assignee)

Updated

7 years ago
Summary: test_localToImapFilterQuarantine.js fails on Linux after bug 580108 → test_localToImapFilterQuarantine.js intermittent timeout on Linux | test failed (with xpcshell return code: 0)
Whiteboard: [orange]
(Assignee)

Updated

7 years ago
Blocks: 596184
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.
(Assignee)

Comment 5

7 years ago
(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)
Created attachment 477060 [details]
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.
(Assignee)

Comment 7

7 years ago
Created attachment 477896 [details] [diff] [review]
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
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
(Assignee)

Comment 8

7 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 9

7 years ago
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.
V.Fixed, confirming comment 8.

Though I had the same thoughts as in comment 9...
Status: RESOLVED → VERIFIED
Flags: in-testsuite+
Target Milestone: --- → Thunderbird 3.3a1
Blocks: 599708
(Assignee)

Comment 11

7 years ago
Thanks fro filing the bug - I was thinking about filing it at the time, but forgot.
Duplicate of this bug: 596184
Attachment #477896 - Attachment description: Possible fix → Possible fix [Checked in: Comment 7]
Keywords: intermittent-failure
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.