test_offlinePlayback.js intermittently failing

RESOLVED FIXED in Thunderbird 3.3a1

Status

MailNews Core
Testing Infrastructure
RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: BenB, Assigned: standard8)

Tracking

({intermittent-failure})

Trunk
Thunderbird 3.3a1
intermittent-failure
Bug Flags:
in-testsuite +

Thunderbird Tracking Flags

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

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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]
(Reporter)

Comment 5

7 years ago
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.
Created attachment 448185 [details] [diff] [review]
Proposed fix

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)
(Reporter)

Comment 8

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

7 years ago
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
Last Resolved: 7 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
status-thunderbird3.1: --- → .1-fixed
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+
Checked in to 1.9.1: http://hg.mozilla.org/releases/comm-1.9.1/rev/2cbfe1e7e95a
status-thunderbird3.0: --- → .9-fixed
Keywords: intermittent-failure
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.