Closed Bug 1309764 Opened 6 years ago Closed 5 years ago

Intermittent test_safe_browsing_initial_download.py TestSafeBrowsingInitialDownload.test_safe_browsing_initial_download | TimeoutException: Timed out after 60.0 seconds with message: Not all safebrowsing files have been downloaded

Categories

(Toolkit :: Safe Browsing, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox56 --- fixed

People

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

References

Details

(Keywords: intermittent-failure)

It's strange here that we get the timeout error but the assert in the finally block doesn't fail:

https://dxr.mozilla.org/mozilla-central/source/testing/firefox-ui/tests/functional/security/test_safe_browsing_initial_download.py?q=TestSafeBrowsingInitialDownload&redirect_type=single#76

It would mean that Firefox downloaded all the needed files but one of the preferences for nextupdatetime hasn't been updated.

Francois, if we have a race in setting the preference, I wonder if we should better check the number of downloaded files and continue when that reached the expected count of files.
Flags: needinfo?(francois)
(In reply to Henrik Skupin (:whimboo) from comment #1)
> It would mean that Firefox downloaded all the needed files but one of the
> preferences for nextupdatetime hasn't been updated.

That's pretty strange, but perhaps the update wasn't completely successful.

If we were to set browser.safebrowsing.debug while running the test (which outputs debug info to the console), would we be able to see that in the taskcluster logs?

> Francois, if we have a race in setting the preference, I wonder if we should
> better check the number of downloaded files and continue when that reached
> the expected count of files.

That should be fine, but I wouldn't mind seeing more output from these failing jobs.

Maybe we should check for the existence of the files and also that the filesize > 0?
Flags: needinfo?(francois)
(In reply to François Marier [:francois] from comment #2)
> If we were to set browser.safebrowsing.debug while running the test (which
> outputs debug info to the console), would we be able to see that in the
> taskcluster logs?

Totally! And that's actually a great idea. I will come up with a patch for that on a new bug and mark current failures depending on it.

> > Francois, if we have a race in setting the preference, I wonder if we should
> > better check the number of downloaded files and continue when that reached
> > the expected count of files.
> 
> That should be fine, but I wouldn't mind seeing more output from these
> failing jobs.
> 
> Maybe we should check for the existence of the files and also that the
> filesize > 0?

Lets defer this once we have new information from the debug output.
Should be fixed by the patch in bug 1371923.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1371923
We are going to increase the timeout value to 90s over on bug 1374268. So this should hopefully fix this problem.
Status: RESOLVED → REOPENED
Depends on: 1374268
Resolution: DUPLICATE → ---
Component: Firefox UI Tests → Safe Browsing
Product: Testing → Toolkit
QA Contact: hskupin
Version: Version 3 → unspecified
This should hopefully be fixed now.
Assignee: nobody → tnguyen
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.