Bug 1295499 - Attempts to update a specific search query results in infinite "Please stand by"
Summary: Attempts to update a specific search query results in infinite "Please stand by"
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Bugzilla
Classification: Community
Component: Query/Bug List
Version: 4.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: PnT DevOps Devs
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-04 17:33 UTC by Tom Lavigne
Modified: 2017-02-01 11:41 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-02-01 11:25:19 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1260009 0 high CLOSED Create a better query builder for Custom Search 2021-02-22 00:41:40 UTC

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!


Note You need to log in before you can comment on or make changes to this bug.