Closed Bug 1332440 Opened 3 years ago Closed 3 years ago
_download _late _used _preload .html | Makes sure that preloaded resources are not downloaded again when used - assert _equals: expected 3 but got 2
this is a new test which was landed and has failed 50 times in the last week :( This is failing on a mix of all configurations, more often on linux than windows/osx. here are some retriggers: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-searchStr=Linux%20x64%20opt%20Web%20platform%20tests%20executed%20by%20TaskCluster%20with%20e10s%20test-linux64%2Fopt-web-platform-tests-e10s-5%20tc-W-e10s(5)&tochange=efeda43ab7b20d9216bf72b5f97a3dd715312e2a&fromchange=52a8ae1e1a82e5f7166001b70d5ab5adb2f26336&selectedJob=70362763 I would argue to backout the change or disable the test until the test owner can make it more stable. :jgraham, can you help me identify the owner of this test. I have you as the test author based on hg commit history, but I suspect this would belong to someone else, you just landed it. Also if you feel you can disable or fix this test, please go ahead and do so.
I strongly suggest just increasing the inner timeout in https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/preload/single_download_late_used_preload.html from 1000 to say 5000 and seeing what happens.
hmm, that didn't help, it seemed to make it worse: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6d22e97cf737d54d92b6db4718a880c75bf720a4 the change: https://hg.mozilla.org/try/rev/30ce478fef6e07fc2aed5dec893622bbca9f1075 :jgraham, as this is so frequent, can we get someone to look at this, or consider disabling it? There is no corresponding OWNERS file, ideally if we could determine which component to put preload stuff in, we could triage it there and find a related developer.
The original test author has a bugzilla account so I guess that's one person to ask :)
jmaher: Increasing the total time for the test to run to 10s means that it always times out since that's the default wpt time limit. That's why I only suggested changing the inner timeout to 5000ms. Per Yoav these tests are expected to fail in gecko, so actually the unexpected fails are the correct behaviour…
Made a fixed version of the test for Yoav to review upstream: https://github.com/w3c/web-platform-tests/pull/4683
checking in here, this is still failing at the same rate and pattern. I see the pull request is merged, do we need to update code in mozilla-central, or does this automatically happen?
Flags: needinfo?(yoav) → needinfo?(james)
Ah. I meant to forward port this, but let's do an update.
:jgraham, I still see a high volume of failures here, can you get this resolved this week?
Should be fixed by the wpt update.
Status: NEW → RESOLVED
Closed: 3 years ago
Depends on: 1340474
Resolution: --- → FIXED
We're going to want to backport a fix to 53 as well. Given that I doubt we want a wholesale update, can you please attach a branch patch?
Doesn't seem to be fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
:jgraham, can you take another look here?
This seems to have at least become much better after the wpt update; I think the conclusion that it wasn't fixed was likely an artifact of the fact that the update got backed out and had to reland. Attached a patch that can land against other branches e.g. aurora.
Status: REOPENED → RESOLVED
Closed: 3 years ago → 3 years ago
Resolution: --- → FIXED
Followup to fix wpt-manifest failures: https://hg.mozilla.org/releases/mozilla-aurora/rev/397bf222b4d4
You need to log in before you can comment on or make changes to this bug.