Bug 1295499

Summary: Attempts to update a specific search query results in infinite "Please stand by"
Product: [Community] Bugzilla Reporter: Tom Lavigne <tlavigne>
Component: Query/Bug ListAssignee: PnT DevOps Devs <hss-ied-bugs>
Status: CLOSED WONTFIX QA Contact: tools-bugs <tools-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.4CC: huiwang, mtahir, qgong
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-01 11:25:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Tom Lavigne 2016-01-04 17:33:47 UTC 
Description of problem:

Attempts to edit a specific search query results in a "Please stand by" that never ends.  Infinite loop?

Version-Release number of selected component (if applicable):


How reproducible:

Always with this one specific query.   I have tried multiple edits to the same query without being able to workaround the problem.

Steps to Reproduce:
1.  Use this URL, which is a relatively complex search query, which DOES finish:  https://url.corp.redhat.com/42c17a4
2. EDIT SEARCH
3. Remove the first line in the query, the "blocks" criteria.
4. Search

Actual results:

"Please stand by" forever

Expected results:

A list of bugs resulting from the updated search.


Additional info:
Comment 1 Jeff Fearn 🐞 2016-01-04 23:12:26 UTC 
I tested this as instructed, and the results are as stated.

I then added:

Classification: Red Hat
Product: Red Hat Enterprise Linux 6

and reran the search, 19 bugs found in ~5 seconds.

The question now is, why doesn't the search timeout like it's supposed to?
Comment 2 Jeff Fearn 🐞 2016-01-04 23:18:44 UTC 
FYI This relates to the way Postgres handles the search and isn't a code loop, the DB is taking a long time to check the "bug_id NOT IN(~1 million ID's)". Setting the product reduces the number of IDs by a factor or two and thus computes reasonably fast.
Comment 3 Jeff Fearn 🐞 2017-02-01 11:25:19 UTC 
The proxy was tweaked recently and this query now correctly dies with the "Your query was taking longer than 120 seconds and had to be killed.  Please back up and narrow your search criteria ..." message.

Given that taking the advice in the message gets a search result I'm going to close this. Jump on Bug 1260009 if you want to pursue improving the search generation.
Comment 4 Tom Lavigne 2017-02-01 11:41:02 UTC 
Agreed, sorry should have closed the bug before.  I left it open in case you wanted to improve the messaging, which it looks like you have done according to comment #3.  Thanks!