Closed Bug 1332440 Opened 8 years ago Closed 8 years ago

Intermittent /preload/single_download_late_used_preload.html | Makes sure that preloaded resources are not downloaded again when used - assert_equals: expected 3 but got 2

Categories

(Testing :: web-platform-tests, defect)

Product:
Testing
Component:
web-platform-tests
Version:
Version 3
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox52 unaffected, firefox53 fixed, firefox54 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla54
Tracking Flags:
Tracking Status
firefox52 --- unaffected
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: jgraham)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed])

Attachments

(1 file)

1332440.diff
(deleted), patch
Details | Diff | Splinter Review
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.
Flags: needinfo?(james)
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.
Flags: needinfo?(james)
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.
Flags: needinfo?(james)
Flags: needinfo?(james) → needinfo?(yoav)
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.
Flags: needinfo?(james)
:jgraham, I still see a high volume of failures here, can you get this resolved this week?
Flags: needinfo?(james)
Should be fixed by the wpt update.
Status: NEW → RESOLVED
Closed: 8 years ago
Depends on: 1340474
Flags: needinfo?(james)
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?
Assignee: nobody → james
status-firefox52: --- → unaffected
status-firefox53: --- → affected
status-firefox54: --- → fixed
Flags: needinfo?(james)
Target Milestone: --- → mozilla54
Doesn't seem to be fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
:jgraham, can you take another look here?
Attached patch 1332440.diff (deleted) — — Splinter Review
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.
Flags: needinfo?(james)
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Whiteboard: [stockwell fixed]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: