Closed Bug 553353 Opened 14 years ago Closed 14 years ago

test_offlinePlayback.js intermittently failing

Categories

(MailNews Core :: Testing Infrastructure, defect)

defect
Not set
normal

Tracking

(thunderbird3.1 .1-fixed, thunderbird3.0 .9-fixed)

RESOLVED FIXED
Thunderbird 3.3a1
Tracking Status
thunderbird3.1 --- .1-fixed
thunderbird3.0 --- .9-fixed

People

(Reporter: BenB, Assigned: standard8)

References

()

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Setup:
- Linux
- TB trunk (cc/mc) without any changes 
Reproduction:
make -s -C mailnews/imap/test/ xpcshell-tests

mailnews/imap/test/unit/test_offlinePlayback.js on fails for me, since at least a week. Please fix it.
(In reply to comment #0)
> mailnews/imap/test/unit/test_offlinePlayback.js on fails for me, since at least
> a week. Please fix it.

All the check tinderboxes which run that test (and build release/static mailnews) are working fine, although admittedly I've seen one or two intermittent failures.

I'd rather have a log output and some idea of what build setup (debug/release) you're using before we tackle this.
This WFM on latest linux trunk and Mac on debug builds. Tinderboxes are covering the release builds.

So without further information (as already requested), this is WFM...
It also failed on http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird3.1/1273588494.1273589712.28310.gz so that might be at least some of the information we need.
It fails intermittently on tinderboxes, and I can reproduce here.

So far, it appears that in test 3 which is when the test goes back online, the authentication with the server is sometimes failing, this then results in the connection not being made correctly, and test 4 failing as a result.
OS: Linux → All
Hardware: x86 → All
Summary: test_offlinePlayback.js failing → test_offlinePlayback.js intermittently failing
Whiteboard: [orange]
FWIW, it's currently not failing for me (so seems to be intermittent indeed), so I can't add more info. Thanks for keeping it in mind and tracking it.
I'm currently testing a fix for it, I think I know what the issue is.
Attached patch Proposed fixSplinter Review
On taking a look at this (as mentioned above), I noticed that authentication step wasn't working properly.

It turns out that before that, when we drop the connection (due to going offline) there is a CLOSE command sent, this seems consistent, however there is also normally a LOGOUT command sent. This doesn't get sent in the failure mode, however the socket connection still gets completely dropped in both states.

In the imap fake server, the LOGOUT command resets the state of the server to requiring AUTH, so if this isn't received we get into the failure state because we can't log into the fake server again.

Therefore I think the fix is to reset the imap fake server handler into the AUTH state (by using its resetTest call) when the socket is closed, I think this simulates what would happen in reality. Hence, when we reconnect it'll work correctly.

I did consider just calling resetTest from test_offlinePlayback.js, but I could see this being hit elsewhere.

All the tests seem to run fine with this in, I've also been running the test_offlinePlayback.js repeatedly and I can't get it to randomly fail now.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #448185 - Flags: review?(bienvenu)
> the socket connection still gets completely dropped in both states.
> In the imap fake server, the LOGOUT command resets the state of the server to
> requiring AUTH, so if this isn't received we get into the failure state because
> we can't log into the fake server again.

resetTest() is the right thing to do in that case, yes.
Please add "including requiring authentication again" to the comment.
Comment on attachment 448185 [details] [diff] [review]
Proposed fix

seems reasonable.
Attachment #448185 - Flags: review?(bienvenu) → review+
Blocks: 438871
Checked in: http://hg.mozilla.org/comm-central/rev/0f9c2e2a6f94
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Attachment #448185 - Flags: approval-thunderbird3.1?
Attachment #448185 - Flags: approval-thunderbird3.1? → approval-thunderbird3.1.1+
Checked into 192: http://hg.mozilla.org/releases/comm-1.9.2/rev/1f4ca702dc0b
Flags: in-testsuite+
Target Milestone: --- → Thunderbird 3.2a1
Comment on attachment 448185 [details] [diff] [review]
Proposed fix

Just seen on 3.0.x so should consider there as well.
Attachment #448185 - Flags: approval-thunderbird3.0.9?
Attachment #448185 - Flags: approval-thunderbird3.0.9? → approval-thunderbird3.0.9+
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: