Closed Bug 1332440 Opened 3 years ago Closed 3 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


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

Version 3
Not set


(firefox52 unaffected, firefox53 fixed, firefox54 fixed)

Tracking Status
firefox52 --- unaffected
firefox53 --- fixed
firefox54 --- fixed


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



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


(1 file)

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:

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 from 1000 to say 5000 and seeing what happens.
Flags: needinfo?(james)
hmm, that didn't help, it seemed to make it worse:

the change:

: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:
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.
Closed: 3 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
Flags: needinfo?(james)
Target Milestone: --- → mozilla54
Doesn't seem to be fixed.
Resolution: FIXED → ---
:jgraham, can you take another look here?
Attached patch 1332440.diffSplinter 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)
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Whiteboard: [stockwell fixed]
You need to log in before you can comment on or make changes to this bug.