572660 - TEST-UNEXPECTED-FAIL | test_mail_account_setup during Thunderbird Mac mozmill tests

Status: RESOLVED FIXED

(Mozilla Messaging Graveyard :: Release Engineering, defect)

Description

[Mark Banner (:standard8)]

On the production tinderboxes (mini-03 to mini-09) we are currently seeing the following test failure when running mozmill tests:

TEST-UNEXPECTED-FAIL |  test_mail_account_setup
  EXCEPTION: timeout exceeded for waitForEval('subject._currentConfigFilledIn != null')
    at: controller.js line 498
       Error("timeout exceeded for waitForEval('subject._currentConfigFilledIn != null')")  0
            controller.js 498
       test_mail_account_setup() test-mail-account-setup-wizard.js 136
            frame.js 468
            frame.js 520
            frame.js 562
            frame.js 411
            frame.js 568
            server.js 164
            server.js 168

I've just noticed this is happening on both comm-central *and* comm-1.9.2. comm-1.9.1 doesn't have this test.

Interestingly, mini-01 and mini-02 running on the staging tinderboxes are not showing this failure, and it is *very* hard to reproduce (i.e. you have to manually intervene to get the test to fail).

For comm-1.9.2, Tinderbox shows a regression range of around 2010/06/15 02:49:53 to 2010/06/15 10:18:36.

There were *no* code changes during this time on the comm-1.9.2 branch, and in fact the last relevant comm-1.9.2 change would have been around 2010/06/08.

Therefore I'm declaring this is a builder issue, though I expect gozer will need ideas of where to look.

Comment 1

[Mark Banner (:standard8)]

Obvious ideas of things to check:

- If the builders can dns lookup, and maybe ping the ispdb (I very much doubt this is the issue).
- If the builders can open ports, I think around the 43300 area. This is for a http connection from mozmill to Thunderbird.

Comment 2

[Blake Winton (:bwinton) (:☕️)]

Attachment: A patch that should let us know whether the fields are being populated.

So, this patch should help in two ways.
1) It will tell us whether the input fields are populated or not (which could indicate a focus problem, or some other problem), and
2) if it is a focus problem, it will let us fail immediately, instead of waiting the eight seconds for the eval string to timeout.

Later,
Blake.

Comment 3

[Blake Winton (:bwinton) (:☕️)]

(In reply to comment #1)
> - If the builders can dns lookup, and maybe ping the ispdb (I very much doubt
> this is the issue).
> - If the builders can open ports, I think around the 43300 area. This is for a
> http connection from mozmill to Thunderbird.

We add a MozMill http resource, which points to <http://localhost:4545/autoconfig>, and set that as the url Thunderbird should hit, and it _should_ contain the config file for example.com, so we shouldn't be hitting the ispdb/autoconfig server, but we do need to hit ourselves on port 4545.

(I'm now going to make sure that we actually load that file without errors.)

Later,
Blake.

Comment 4

[Blake Winton (:bwinton) (:☕️)]

Yeah, it looks like it works from here.
(I added 'pref.setCharPref("mail.wizard.logging.dump", "All");' after 'pref.setCharPref(pref_name, url);', and the output looked like the file got loaded and parsed correctly.

Comment 5

[Philippe M. Chiasson (:gozer)]

(In reply to comment #1)
> Obvious ideas of things to check:
> 
> - If the builders can do dns lookup, and maybe ping the ispdb (I very much doubt
> this is the issue).

No problem there, but apart from ispdb.mozillamessaging.com, what else would they be resolving ? (and generally, why does such a test even needs DNS resolution?)

> - If the builders can open ports, I think around the 43300 area. This is for a
> http connection from mozmill to Thunderbird.

I don't why they wouldn't be able to do that, and nothing changed on these builders, so if they were able to before, they should still be able to.

Comment 6

[Philippe M. Chiasson (:gozer)]

Turns out the minis were configured with a first nameserver that didn't respond, adding an additional 2second delay to dns queries. Fixed.

Comment 7

[Blake Winton (:bwinton) (:☕️)]

(In reply to comment #5)
> (In reply to comment #1)
> > Obvious ideas of things to check:
> > - If the builders can do dns lookup, and maybe ping the ispdb (I very much doubt
> > this is the issue).
> No problem there, but apart from ispdb.mozillamessaging.com, what else would
> they be resolving ? (and generally, why does such a test even needs DNS
> resolution?)

Just for posterity, the autoconfig hits http://autoconfig.<domain>/something.xml before hitting the ispdb, which is why it needs DNS resolution.  We set it to example.com, to avoid getting any actual hosts.  And we set the ispdb url to the MozMill collector so that we don't even hit the actual ispdb.

Later,
Blake.