640543 - Random orange: TEST-UNEXPECTED-FAIL | test-retest-config.js | test_re_test_config

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Mark Banner (:standard8)]

We were getting a few issues with random oranges on the account wizard before, but since the latest changes, we're getting slightly different ones:

TEST-PASS | test_remember_password
TEST-UNEXPECTED-FAIL | test-retest-config.js | test_re_test_config
  EXCEPTION: timeout exceeded for waitForEval('subject.disabled == false && subject.hidden == false')
    at: controller.js line 499
            controller.js 499
            test-retest-config.js 87
            frame.js 469
       WindowWatcher_notify([object XPCWrappedNative_NoHelper]) test-window-helpers.js 255
TEST-UNEXPECTED-FAIL | (runtestlist.py) | Exited with code 1 during directory run

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

This wins the first mozmill failure that shows up in the Thunderbird tree on mozmill for arbpl award:

http://arbpl.visophyte.org/?tree=Thunderbird&pushid=5603&log=19178%3A1299790976.1299791885.27652.gz

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

And this is totally the same thing as my complaint from bug 568153 comment 51:

hey, so I just got an intermittent orange on test_re_test_config in
test-retest-config.js, the test added for this bug...

I could not help but notice that the e-mail address used for the test is
"[e-mail]", that we then actually do a bunch of DNS lookups against
yahoo.com, and even try and talk to the POP server.  (It took my local run 30
seconds to get a RST response to my SYN packets...*).  This probably explains
why the test has a 100second timeout for the first step and 20 second timeouts
for the following tests.

Can we back this test out entirely in preparation for the next phase of
autoconfig stuff?  If not, can we make it locally standalone (it looks like
test-mail-account-setup-wizard.js might operate along those lines), or failing
that, point at MoMo-hosted test servers?

* Should I have gotten an actual response?  Is it possible that MoMo YVR's IP
is blacklisted by Yahoo's pop server because our mac minis are poking it all
day long with bogus logins?

Comment 3

[Rain [:rain1] (inactive)]

Related to bug 604356? Seems like making the accesses purely local will fix both that and this. I mentioned a few possible solutions there.

Comment 4

[Jonathan Protzenko [:protz]]

Andrew, I've added a parameter to wait_for_modal_dialog that allows the user to pass a custom timeout value. That custom value is, in that very test, 30000. But your (awesome) failure breakdown gives 400-ish + 8400-ish ms. of waiting before the timeout... (grey text near the bottom of the link you point to in comment #1).

Comment 5

[Mark Banner (:standard8)]

Attachment: Proposed fix

Lets try this. Change the domain to "momo.invalid", and provide it via the local http server.

This should mean virtually no external lookups, and hopefully an always green test.

Comment 6

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/a2f292b3bfcc