Closed Bug 1308679 Opened 5 years ago Closed 5 years ago
_httpauth .js | This test exceeded the timeout threshold . It should be rewritten or split up . If that's not possible, use request Longer Timeout(N), but only as a last resort . -
58 bytes, text/x-review-board-request
Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=4720125&repo=autoland https://archive.mozilla.org/pub/firefox/tinderbox-builds/autoland-linux-debug/1475848380/autoland_ubuntu32_vm-debug_test-mochitest-e10s-browser-chrome-1-bm07-tests1-linux32-build50.txt.gz
This test got implemented in bug 1301523 and fails 6-12 times a day. jhao, can you take a look at this, please?
I'm seeing this trigger a lot in a try build. I think bug 1301340 made this worse on Oct 12 by changing the timing of the cleanup code. Due to the second set of prefs being set flushPrefEnv() is now taking longer and seems to hang. If I revert back to a single set of prefs the frequency of the problem is reduced. Its unclear to me what this is racing against, though. It seems the test should be waiting for something before proceeding.
Well, I'm less sure now if that is the problem. But the failures did increase around Oct 12 when bug 1301340 landed. Its worth checking to see if it increased the frequency.
Assignee: nobody → jhao
Ben, can you find an assignee who works on this? jhao is on pto and this bug should be fixed before the merge (Nov 7th), there wouldn't be much time left for this after jhao's return (Nov 3rd). Thank you.
I'm sorry, but I don't really know who would be a good person to work this. In theory someone who has worked on the first party isolation or someone in the firefox org familiar with browser chrome testing.
Arthur, please take a look at comment 11.
:ethan, can you help find somebody else on :jhao's team to look at this bug?
Nearly all of these failures are on Linux Debug, with most of those on e10s. If you look at successful runs of this test on Linux Debug, e10s, they generally take between 40 and 45 seconds to complete. That holds true even on runs when the test was first implemented. Consider this log from 2016-10-08: https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux-debug/1475895442/mozilla-central_ubuntu32_vm-debug_test-mochitest-e10s-browser-chrome-1-bm07-tests1-linux32-build2.txt.gz 252 INFO TEST-OK | browser/components/originattributes/test/browser/browser_httpauth.js | took 45322ms mochitest-bc tests will time out if they take >45 seconds, so I think these failures are just a product of a long-running test running just a bit longer. I don't see an obvious way to split it up, so perhaps requestLongerTimeout() is the best way forward?
yeah, I don't see anything wrong with requestLongerTimeout()- it isn't good as it can lead to longer running tests, but in this case it gets us past a recurring issue until we can revisit the test.
(In reply to Joel Maher ( :jmaher) from comment #17) > :ethan, can you help find somebody else on :jhao's team to look at this bug? Tim, please help to look into this bug.
Flags: needinfo?(ettseng) → needinfo?(tihuang)
I think the requestLongerTimeout() would be a better way to resolve this problem since the test framework here will run the same test three times with different settings. So, the test here represents three tests. Maybe we could find a way that to split one test into three test files, but I think this is not a good solution here because it is hard to maintain, and would be annoying when adding new test cases. Baku, do you have any suggestion for this? Or we could use requestLongerTimeout() to address this issue.
Flags: needinfo?(tihuang) → needinfo?(amarchesini)
Comment on attachment 8805836 [details] Bug 1308679 - Request a longer timeout for the tests that use first party isolation test framework. https://reviewboard.mozilla.org/r/89466/#review88732
Attachment #8805836 - Flags: review?(amarchesini) → review+
Try looks good.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/6abc545be46e Request a longer timeout for the tests that use first party isolation test framework. r=baku
(In reply to OrangeFactor Robot from comment #34) > For more details, see: > https://brasstacks.mozilla.com/orangefactor/ > ?display=Bug&bugid=1308679&startday=2016-10-31&endday=2016-11-06&tree=all It seems the intermittent was really resolved. :)
You need to log in before you can comment on or make changes to this bug.