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

RESOLVED FIXED

Status

--
critical
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: standard8, Assigned: gozer)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
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.
Component: Testing Infrastructure → Server Operations
Product: Thunderbird → Mozilla Messaging
QA Contact: testing-infrastructure → server-ops
Version: Trunk → other
Component: Server Operations → Release Engineering
QA Contact: server-ops → release
Created attachment 451918 [details] [diff] [review]
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.
(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.
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.
(Assignee)

Comment 5

8 years ago
(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.
(Assignee)

Comment 6

8 years ago
Turns out the minis were configured with a first nameserver that didn't respond, adding an additional 2second delay to dns queries. Fixed.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(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.
You need to log in before you can comment on or make changes to this bug.