Closed
Bug 1309764
Opened 8 years ago
Closed 7 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)
Toolkit
Safe Browsing
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox56 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: tnguyen)
References
Details
(Keywords: intermittent-failure)
Comment 1•8 years ago
|
||
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)
Comment 2•8 years ago
|
||
(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)
Updated•8 years ago
|
Comment 3•8 years ago
|
||
(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.
Comment hidden (Intermittent Failures Robot) |
Comment 5•7 years ago
|
||
Should be fixed by the patch in bug 1371923.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 8•7 years ago
|
||
We are going to increase the timeout value to 90s over on bug 1374268. So this should hopefully fix this problem.
Updated•7 years ago
|
Component: Firefox UI Tests → Safe Browsing
Product: Testing → Toolkit
QA Contact: hskupin
Version: Version 3 → unspecified
Comment 9•7 years ago
|
||
This should hopefully be fixed now.
Assignee: nobody → tnguyen
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
status-firefox56:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in
before you can comment on or make changes to this bug.
Description
•