Closed Bug 584327 Opened 10 years ago Closed 10 years ago

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

Categories

(MailNews Core :: Filters, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3.3a1

People

(Reporter: standard8, Assigned: standard8)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure, regression)

Attachments

(4 files)

Attached file 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.
Attached file "pass" log
The "pass" case is definitely waiting for a timeout - I discovered that when generating the log.
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 :-)
actually, adding timestamp to the imap log would be helpful, as well as turning on the pop3 logging...
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]
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.
(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)
Got this last night at the 29. run of the mailnews xpcshell-tests on Linux. So still there but quite rare.
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
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
Closed: 10 years ago
Resolution: --- → FIXED
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
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]
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.