Closed
Bug 1203764
Opened 9 years ago
Closed 9 years ago
Failure in test_clock_create_new_alarm.py in self.alarm_alert.wait_for_alarm_to_trigger()
Categories
(Firefox OS Graveyard :: Gaia::UI Tests, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: martijn.martijn, Assigned: martijn.martijn)
References
()
Details
Attachments
(1 file)
This test is failing again, the alarm is set 3 minutes after the current time. wait_for_alarm_to_trigger wait time is 60 second, so that's why it's failing there. TEST-START | test_clock_create_new_alarm.py TestClockCreateNewAlarm.test_clock_create_new_alarm TEST-UNEXPECTED-ERROR | test_clock_create_new_alarm.py TestClockCreateNewAlarm.test_clock_create_new_alarm | TimeoutException: TimeoutException: Timed out after 61.3 seconds Traceback (most recent call last): File "/Users/mwargers/.virtualenvs/test3/lib/python2.7/site-packages/marionette_client-0.17-py2.7.egg/marionette/marionette_test.py", line 296, in run testMethod() File "/Users/mwargers/B2G/gaia_clean/tests/python/gaia-ui-tests/gaiatest/tests/functional/clock/test_clock_create_new_alarm.py", line 94, in test_clock_create_new_alarm self.alarm_alert.wait_for_alarm_to_trigger() File "/Users/mwargers/B2G/gaia_clean/tests/python/gaia-ui-tests/gaiatest/apps/clock/regions/alarm_alert.py", line 17, in wait_for_alarm_to_trigger expected.element_present(*self._alarm_frame_locator)) File "/Users/mwargers/.virtualenvs/test3/lib/python2.7/site-packages/marionette_driver-0.13-py2.7.egg/marionette_driver/wait.py", line 143, in until cause=last_exc) TEST-INFO took 171335ms SUMMARY ------- passed: 0 failed: 1 todo: 0
Comment 1•9 years ago
|
||
Assignee | ||
Comment 2•9 years ago
|
||
Comment on attachment 8659609 [details] [review] [gaia] mwargers:1203764 > mozilla-b2g:master This makes the test pass again. The interval=5 part is not really necessary, but I don't think Marionette needs to poll that much, while it's waiting for the alarm to appear.
Attachment #8659609 -
Flags: review?(npark)
Attachment #8659609 -
Flags: review?(jlorenzo)
Comment 3•9 years ago
|
||
Comment on attachment 8659609 [details] [review] [gaia] mwargers:1203764 > mozilla-b2g:master At a first glance, the patch doesn't seem bad. I'm not sure of the effects of it, though. I ran this test many times this week and I've never seen the problem. Here's a Jenkins job[1] ran this week. It passed 31/31 times. I tried to repro it today with the lastest Flame and yesterday's Aries, no repro. I won't have time to investigate it more, today. Moving the review to John, in case he's more (un?)lucky to get the failure. [1] http://jenkins1.qa.scl3.mozilla.com/job/flame-kk.ui.adhoc/887/console
Attachment #8659609 -
Flags: review?(jlorenzo) → review?(jdorlus)
Assignee | ||
Comment 4•9 years ago
|
||
I'm very surprised that it's passing for you, Johan, and also that the Jenkins adhoc run is passing. For me, it's consistently failing on the latest Flame. It also consistently seems to fail on bitbar at least. I think Nicholas also did an adhoc job for this, where it consistently failed. Perhaps Nicholas could give an insight where it is failing. Perhaps it's failing in bitbar, but not in the Mountain View lab or something?
Flags: needinfo?(nnelson)
Comment 5•9 years ago
|
||
Comment on attachment 8659609 [details] [review] [gaia] mwargers:1203764 > mozilla-b2g:master For me, without this patch, the test fails consistently, and after the patch the test starts passing. I guess some timing issue is involved?
Attachment #8659609 -
Flags: review?(npark) → review+
Comment 6•9 years ago
|
||
This test seems to be failing consistently in bitbar, I haven't observed Mountain View tests for Smoke for a while. When I ran this locally, I observed it create a new alarm and time out on the home screen waiting for it to trigger. It looked like the alarm was set to 3 minutes in the future, so maybe it's just that the wait time is exceeding the time out on the test.
Flags: needinfo?(nnelson)
Comment 7•9 years ago
|
||
Having a JSON read error right now. Continuing to troubleshoot.
Assignee | ||
Comment 8•9 years ago
|
||
Comment on attachment 8659609 [details] [review] [gaia] mwargers:1203764 > mozilla-b2g:master Today, I could reproduce the same thing as Johan on my Aries device. Namely, that it was working there without the pull request, but then not with the pull request. After a lot of trial and error, I think I have now something that should work reliable across all devices. So that's why I removed the TODO comments, because this seems to work well. The trick was to add .wait() calls to the Actions() thing. Apparently, that is necessary to get a reliable flick action. Something to think about next time it is needed. Please let me know if this works correctly on your device(s).
Attachment #8659609 -
Flags: review+ → review?(npark)
Comment 9•9 years ago
|
||
This timeout error happens for me but at a different place.
Assignee | ||
Comment 10•9 years ago
|
||
What timeout error? If it happens in a different place, then it's a different timeout error, no?
Comment 11•9 years ago
|
||
Comment on attachment 8659609 [details] [review] [gaia] mwargers:1203764 > mozilla-b2g:master It's passing for me consistently on multiple runs
Attachment #8659609 -
Flags: review?(npark) → review+
Comment 12•9 years ago
|
||
Updated base image. Run this 10/10 times. All passing.
Comment 13•9 years ago
|
||
Comment on attachment 8659609 [details] [review] [gaia] mwargers:1203764 > mozilla-b2g:master >https://github.com/mozilla-b2g/gaia/pull/31794
Attachment #8659609 -
Flags: review?(jdorlus) → review+
Assignee | ||
Comment 14•9 years ago
|
||
Merged: https://github.com/mozilla-b2g/gaia/commit/009c283216e3c8d36ccb01cd7a81b657f91431e2
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•