1309764 - 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

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect)

Description

[Treeherder Bug Filer]

Filed by: philringnalda [at] gmail.com

https://treeherder.mozilla.org/logviewer.html#?job_id=4963332&repo=autoland

https://queue.taskcluster.net/v1/task/F0RpJqqxQra9-b5SnllPhg/runs/0/artifacts/public%2Flogs%2Flive_backing.log

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 2

[François Marier [: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?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(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 4

[Intermittent Failures Robot]

8 failures in 814 pushes (0.01 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* mozilla-beta: 8

Platform breakdown:
* windows7-32-vm: 4
* windows10-64-vm: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1309764&startday=2017-06-12&endday=2017-06-18&tree=all

Comment 5

[François Marier [:francois]]

Should be fixed by the patch in bug 1371923.

Comment 6

[Intermittent Failures Robot]

3 failures in 656 pushes (0.005 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* try: 1
* mozilla-central: 1
* autoland: 1

Platform breakdown:
* windows7-32-vm: 1
* osx-cross: 1
* linux64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1309764&startday=2017-07-03&endday=2017-07-09&tree=all

Comment 7

[Intermittent Failures Robot]

2 failures in 720 pushes (0.003 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* mozilla-inbound: 1
* mozilla-central: 1

Platform breakdown:
* windows7-32: 1
* windows10-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1309764&startday=2017-07-10&endday=2017-07-16&tree=all

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We are going to increase the timeout value to 90s over on bug 1374268. So this should hopefully fix this problem.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This should hopefully be fixed now.