Bug 211411

Summary:	bugzilla loses change states
Product:	[Community] Bugzilla	Reporter:	Don Zickus <dzickus>
Component:	Bugzilla General	Assignee:	Bernd Groh <bgroh>
Status:	CLOSED DEFERRED	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	devel	CC:	ebaak
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-11-30 00:08:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Don Zickus 2006-10-18 22:15:44 UTC

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-19 00:16:22 UTC

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-19 03:33:28 UTC

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 14:31:35 UTC

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 14:41:57 UTC

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 14:58:25 UTC

Thanks, I'll give that a whirl..

Comment 6 Bernd Groh 2006-11-30 00:08:35 UTC

Closing this bug now as DEFERRED, as it is an issue we should look at in future.