Bug 1388695

Created attachment 1214299 [details]
Screenshot of activity overlay on advanced search

Encountered during cfme.tests.infrastructure.test_advanced_search_providers.test_filter_save_cancel()

Martin,

Can you help with this BZ, i was not able to recreate this in UI, seems to be only happening in automated test environment.

Thanks,
~Harpreet

This is very probably another request ordering issue, these buttons are still using RJS to call ruby methods, so they do not pass through the observer queue => they can get reordered when clicked too fast.

If that's the case, we can simply change the advanced search form buttons (or maybe just the commit button) to not use :remote but use :onclick with miqObserveRequest instead.


However, Mike, I'd still like to see some more details, especially since this apparently happens only in Infra Providers .. Can you provide the server log from when that happens too please? 

(And, I'm assuming this happens in save_filter, right after sel.click(button), is that correct?)

Infra Providers just happens to be the automation test I'm working at the moment, I did not mean to imply that it is only happening there.

Attached are evm.log, production.log, and automation.log from an appliance where I recreated the hang this morning, local timestamp from the test where the hang occurred was:  2016-10-27 11:11:26,617

I am continuing to test, but it does not appear that the freeze is related to clicking save, and it may occur while opening/closing the search box.

Created attachment 1214656 [details]
CFME logs

Time on local test box for steps immediately leading up to search box hang: 
2016-10-27 11:11:27,091

Dan, this is causing us a lot of grief in terms of test automation and although not necessarily impacting customers, it impacts QE.   Can we get someone looking at this sooner than later.

Dan,

I will look into implementing Martin Hradil's suggestions.

~Harpreet

Mike,

Can you point me to which log in the attached logs i should be looking at for automate tests, or paste me snippet from logs from the time you experienced the issue so i can try to look at the code that is called upon from tests.

Please provide exact test steps and at what point you see infinite spinner, do you see it when a specific button is pressed or when toggling between showing/hiding advanced search panel. 

Thanks,
~Harpreet.

Harpreet,

Thanks for taking action on this.

The attached logs (Oct 27) are from the CFME appliance, not automation logs.

Link [0] is a jenkins execution that failed due to the spinner, and this failure is at a different point than I had seen before. The traceback indicates automation had opened the window and was attempting to click the reset button.

I believe all other failures occured when there was a user-input filter expression committed, and the the search window was opened in order to click save.


[0] http://10.16.45.124/GVTNc6zE/artifacts/report.html

https://github.com/ManageIQ/manageiq/pull/12373

New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/39b6c347d35560152070e842c7b9d79875ad361d

commit 39b6c347d35560152070e842c7b9d79875ad361d
Author:     Harpreet Kataria <hkataria>
AuthorDate: Wed Nov 2 14:37:21 2016 -0400
Commit:     Harpreet Kataria <hkataria>
CommitDate: Wed Nov 2 14:37:21 2016 -0400

    Converted form buttons to go thru miqObserveRequest JS method.
    
    Changed buttons on advanced search to call MiqAjaxButton JS method so trnasactions queue up and are sent upto server in an order they were clicked on to address an issue seen in automated tests.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1388695

 app/views/layouts/_adv_search_footer.html.haml | 123 +++++++++----------------
 1 file changed, 46 insertions(+), 77 deletions(-)

Verified in CFME 5.8.0.4, automation no longer hits an activity spinner that never clears.