Closed Bug 553353 Opened 10 years ago Closed 10 years ago
_offline Playback .js intermittently failing
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
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.
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+
Status: ASSIGNED → RESOLVED
Closed: 10 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
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
You need to log in before you can comment on or make changes to this bug.