Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 211411 - bugzilla loses change states
bugzilla loses change states
Status: CLOSED DEFERRED
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
devel
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: Bernd Groh
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-18 18:15 EDT by Don Zickus
Modified: 2014-06-18 04:21 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-29 19:08:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Don Zickus 2006-10-18 18:15:44 EDT
Description of problem:
I have been using the XML-RPC interface to bugzilla to change the status of
rhel-5 kernel bugs to MODIFIED.  When I try to change anything less than
(around) 13 bugs, it usually works (just takes a looong time, ie 10 minutes or
so and the XML-RPC times out, but that's another issue).  However, it seems
anything over 13 (this is a rough number) only about 13 bugs are modified and
the rest sit in their original status.  I have to take the new list and re-try
setting them to MODIFIED.  This usually works after a few tries.

My problem is I usually batch my commits and check them in around 20 at a time
(just because of the influx of patches, its hard sometimes to do less and keep
up).  So I run into this alot.

I don't like the gui because currently i have everything automated from
changelog to cvs commit to bugzilla state MODIFIED.  

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

How reproducible:
reliably

Steps to Reproduce:
1. using the perl XML-RPC system.multicall, batch about 20 commands together
2. wait until it times out
3. wait some more
4. check status of bugs
  
Actual results:


Expected results:


Additional info:
Comment 1 Bernd Groh 2006-10-18 20:16:22 EDT
Don't you get a return status that allows you to see whether the call was
successful or not?

Dave, could you please help us with this?
Comment 2 David Lawrence 2006-10-18 23:33:28 EDT
Unfortunately the system.multicall does not return a success/fail code until all
calls are completed successfully. That is the nature of XMLRPC itself. It only
prints the data structure containing the response at the very end. Have you
tried  just calling bugzilla.changeStatus() from your client multiple times
instead of using system.multicall? This may should you if one or more are
failing somewhere or which bugs are taking the longest. Remember some bugs are
part of blocker bugs and alot of processing is required to notified all people
attached to each of the bugs. Single bugs not connected to other bugs with only
a few email recipients should process rather quickly.
 
Comment 3 Don Zickus 2006-10-19 10:31:35 EDT
Calling bugzilla.changeStatus multiple times is probably a good work around.  I
just suck at writing perl so while converting from a system.multicall isn't too
difficult (modify the loop to instead of pushing to execute the call).  But
collecting the output so I can display it might give me indigestion (maybe I
don't care for output though..).  Thanks.
Comment 4 David Lawrence 2006-10-19 10:41:57 EDT
The only thing i thing that gets returned is who was/wasn't emailed about the
change. So you typically just ignore that.

perl code would look like:

use XMLRPC::Lite;
use Data::Dumper;

my @bugids = [1434,34554,34553]
my @results = ();

my $rpc = new XMLRPC::Lite
(proxy=>'https://bugzilla.redhat.com/bugzilla/zmlrpc.cgi');

foreach my $id (@bugids) {
    my $call = $rpc->call('bugzilla.changeStatus', 'MODIFIED', $username,
$password);
    push (@results, $call->result);
}

print Dumper(\@results);
Comment 5 Don Zickus 2006-10-19 10:58:25 EDT
Thanks, I'll give that a whirl..
Comment 6 Bernd Groh 2006-11-29 19:08:35 EST
Closing this bug now as DEFERRED, as it is an issue we should look at in future.

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