Originally reported as https://engineering.redhat.com/rt/Ticket/Display.html?id=375942 Changing a lot of bugs at once results on timeouts on Bugzilla proxy. This will be presumably fixed in Bugzilla 5.0 upgrade. This bug is to track this work and making sure we run our tests for that scenario. Original text of the report: Change several bugs at once Does not work. Run a query, any query. e.g. Net-serve-not-reviewed <https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=Net-serve-not-reviewed> query. But any search is fine that will give you 100 BZ or more. Click "Change Several bugs at once" Click check all. Try to do anything, simplest of things like add an email list to the CC list. Hit Commit Bugzilla will not respond for several minutes and then You will get Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request /POST /process_bug.cgi <https://bugzilla.redhat.com/process_bug.cgi>/. Reason: *Error reading from remote server* ------------------------------------------------------------------------ Apache Server at bugzilla.redhat.com Port 443 Kindly please fix this IF you want me to show the problem to you, I can show it via Blue Jeans session No problem. This problem has been there for at least 4 years. So please do consider this as a high priority item.
Note that the bulk-update operation does complete successfully, despite the UI giving a proxy timeout. That's why this issue hasn't received high priority in the past.
I also want to reiterate - this is a user experience issue but does not actually affect the functionality. It's just ugly.
I would like to point out that most of the users do NOT know that the operation completed. How will they know? They just get a time out error Usually getting an error like "Operation Timeout, error" or something like that means the operation DID not complete. So no one is using this bulk changing feature because they think it errors out. Either take the feature out, or fix it. The current state of affairs is sub-optimal at best, awful at worst
Moving this to sprint 48 as it requires QE, but it won;t be QE'able until we have a server behind a proxy with a timeout set.
Any updates? Is it fixed now? When we will see it in production? Silence is deafening. Almost 4 months without status update.
This fix is part of Bugzilla 5 and will go in to production with the Bugzilla 5 upgrade. Currently Bugzilla 5 has gone to QE for it's first QE review, it'll probably need a few reviews to pass QE. I do not have a date for the Bugzilla 5 upgrade. Muhammad, where can people find the Bugzilla 5 schedule?
Moving this so it can be tested by QE, see https://bugzilla.redhat.com/show_bug.cgi?id=1328678#c6 for a suggestion on how to imitate an F5 layer.
Tested on QA environment(5.0.2-rh7) Result: Pass Steps: 1. Install and config the squid in the qe server, start it 2. Config my firefox browser to using this proxy 3. Bach change 366 bugs, add 2 members to cc list, commit ==>It could return the batch update successful page after 6 minutes. ==>All bugs updated.
Hi Jeff, Current release should mean the release that is available for users to use I just tried it with 268 BZs and I got this error. ========== Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /process_bug.cgi. Reason: Error reading from remote server Apache Server at bugzilla.redhat.com Port 443 ============== Please do not close the BZ until it is really fixed. Thanks
BTW, I do not think this BZ has anything to do with 1318898 As I can select all the 268 BZ in my querry. Yet I still get errors when I try to "change several bzs at once"
NEXTRELEASE is not CURRENTRELEASE, and it's the 5.x version of not the 4.x version, so it won't be in production until that server is migrated to the 5.x series. It is not fixable in 4.x so it won't be addressed until the migration to the 5.x series.
Have you verified that the bug is fixed with 5.x? Has anyone in the QA team verified that it is fixed with 5.x? If it is not verified that it is fixed, the why are you closing the bug? To me it seems like you are in a hurry to close the bug, way before it is available for users to use / try. When is 5.x going to be available ?
(In reply to Rashid Khan from comment #14) > Have you verified that the bug is fixed with 5.x? > Has anyone in the QA team verified that it is fixed with 5.x? Comment 10 shows that this item was verified by the Quality Engineer assigned to Bugzilla. > To me it seems like you are in a hurry to close the bug, way before it is > available for users to use / try. The bug satisfies the Bugzilla team's Definition of Done, so it makes sense to me that they closed it (and they did correctly mark it as NEXTRELEASE rather than CURRENTRELEASE). The alternative would be to leave the bug sitting in VERIFIED until Bugzilla 5 is deployed. In my opinion, setting the bug to CLOSED/NEXTRELEASE gives a clearer indication of the status than leaving the bug in VERIFIED for a potentially lengthy period. The latter would create some uncertainty about whether the bug is planned for a release or has simply been forgotten. Additionally, given the large number of bugs being fixed for BZ5, leaving them all in VERIFIED would clutter the backlog with a large number of items for which there is no more development or QE work to be done. (Disclosure: I used to be the Product Owner for Bugzilla, but haven't worked on it since late-2015. Now I'm just a keen observer.)
*** Bug 1277363 has been marked as a duplicate of this bug. ***