http://jenkins1.qa.scl3.mozilla.com/view/UI/job/flame-kk-319.mozilla-central.ui.functional.non-smoke.1/87/HTML_Report/ test_call_log_groups is failing on Jenkins. On local device it fails constantly (5 out of 5). The issue cannot be reproduced manually. From the screenshot it looks like the calls are in the wrong order.

I investigated this further, but cannot find the issue seen in the test run. Gabriele or Anthony, can you please take a look at the attachments? Maybe you can find the problem. Below are the links to the test and the insert methods: https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/test_call_log_groups.py https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/gaiatest/gaia_test.py#L381 https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/gaiatest/mocks/mock_call.py

I'm not involved with Dialer that much so I'll let Gabriele take a look.

This is most likely caused by bug 1112577. Let's check again once I land the fix for that one.

Robert, can you check if this is still an issue? I've landed bug 1112577 which should have solved the issue here.

Robert has left the project. Stealing his NI. Started adhoc job with 100 tries: http://jenkins1.qa.scl3.mozilla.com/view/UI/job/flame-kk.ui.adhoc/703/console

It looks like it's still failing; I think you can stop the job right away. We'll need to investigate this in detail.

Right, I stopped the job. Let me check how's it going locally.

Perma failing. I see exactly the same behavior as in the screenshot attached :s FWIW, we inject the call log entries with: > window.wrappedJSObject.CallLogDBManager.add(callLogEntry); and we add them not in chronological order; today is added before yesterday which is before 2014, itself before 2013: https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/test_call_log_groups.py#L30 Should this behavior be okay with the new CallLogDBManager?

(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #10) > Should this behavior be okay with the new CallLogDBManager? I thought this was due to a race but apparently it is not. It must be an issue in the call log database logic, this is still valid then.

Afaik, this is also an issue on mozilla-central, so removing the [v2.2] part of the summary. Gabriele, do we need to recheck if this is still an issue? Or do you expect this to be still a problem?

I think this is an instance of bug 1151627 so it should still be a problem. I haven't time to fix that one yet but I hope to be able to before the end of June.

Firefox OS is not being worked on