1143222 - Figure out the intermittent failures in the newly added DOM cache tests

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[(no longer active)]

These are failing a lot it seems.

Comment 1

[(no longer active)]

Disabled the tests for now: https://hg.mozilla.org/integration/mozilla-inbound/rev/cb02d5dd0895

Comment 2

[(no longer active)]

Trying to get some frequency info on this try push:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ec238ff02540

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Ehsan, is there some pref to set now to avoid the SW getting queued due to max workers per origin limit?

Comment 4

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/cb02d5dd0895

Comment 5

[(no longer active)]

(In reply to Ben Kelly [:bkelly] from comment #3)
> Ehsan, is there some pref to set now to avoid the SW getting queued due to
> max workers per origin limit?

It's dom.serviceWorkers.exemptFromPerDomainMax which we set in driver.js.

So I haven't yet looked into why these failures happen, but they definitely only happen on parallel runs:

<https://treeherder.mozilla.org/#/jobs?repo=try&revision=121594709250>

So I have re-enabled the tests and for now have set them to run sequentially for now:

<https://hg.mozilla.org/integration/mozilla-inbound/rev/d5bf133711c4>

Comment 6

[(no longer active)]

Discoveries so far:

1. The failures seem to only happen when the service worker doesn't start up at all after finishing the sequential mode and entering the parallel mode.
2. ThreadSanitizer doesn't discover a race when this happens.

Comment 7

[(no longer active)]

Attachment: Avoid dumping out extremely long response bodies to the mochitest log, and re-enable the newly added DOM cache tests to run both in seqential and parallel modes

The test timeouts here are some form of bug 1141256, which causes the service
worker spawned in the parallel mode of the tests to never start up.  It turns
out that avoiding sending this huge message to the mochitest logger avoids the
issue on the infrastructure, so let's re-enable these tests.  Bug 1141256 still
needs to be investigated.

Comment 8

[(no longer active)]

The try run for the patch in comment 7: <https://treeherder.mozilla.org/#/jobs?repo=try&revision=646ae17913b1>

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d5bf133711c4

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 8578357 [details] [diff] [review]
Avoid dumping out extremely long response bodies to the mochitest log, and re-enable the newly added DOM cache tests to run both in seqential and parallel modes

Review of attachment 8578357 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/cache/test/mochitest/test_cache_matchAll_request.js
@@ +18,5 @@
>    is(r.statusText, response.statusText,
>       "Both responses should have the same status text");
>    return r.text().then(function(text) {
> +    // Avoid dumping out the large response text to the log if they're equal.
> +    if (text != responseText) {

nit: !==

::: dom/cache/test/mochitest/test_cache_match_request.js
@@ +16,5 @@
>    is(r.statusText, response.statusText,
>       "Both responses should have the same status text");
>    return r.text().then(function(text) {
> +    // Avoid dumping out the large response text to the log if they're equal.
> +    if (text != responseText) {

nit: !==

Comment 11

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/161eb635963d

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/161eb635963d

Comment 13

[(no longer active)]

Putting these tests in sequential mode again: https://hg.mozilla.org/integration/mozilla-inbound/rev/95288585a32c

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/95288585a32c