Bug 426263

Question:

what happens when the xmlrpc calls fail between Bugzilla & Issue Tracker and
vice versa?

Is the data left in an inconsistent state?

Could we queue failed queries up in a database table that a cron job could pick
up and run later on?

Task:

evaluate & add documentation (in Bz in the perldoc) about the impact of failure
when xmlrpc fails to IT. Evaluate if we are handling these situations correctly.

Subject: 	Re: [engineering.redhat.com #13889]
Date: 	Fri, 13 Jul 2007 15:03:41 -0400
To: 	engineering-services
From: 	Lisa Davidson <llu>

From I-T to BZ, when an event is propagated to BZ successfully, a record
is recored in a table. On I-T UI, it will display in this format to the
RH users:
event sent to $bug $at_this_time by $this_user as $private/$public
Once an event is sent successfully, I-T user can't propagate the event
to the same bug any more.

If an event failed t propagate to BZ, I-T errors end user on the web UI.
It will allow the end user to try as many time as they want to until it
succeeds.

Regarding the failed IT score update, there is a nightly cron job to
update BZ.

Lisa

From: kbaker

There is an idea of storing failed xmlrpc calls in a table for later process by
a cron job.

Psuedo code:

in package

EVAL callIT( @args )
IF failed
queueCallITlater( @args )
ENDIF

later in a cron space far away

FOR each queued IT call
IF call has to many errors THEN
notify bugzilla maintainer
next
ENDIF

EVAL callIT( @args )

IF failed THEN
count error
leave on queue for a later run
ELSE
remove from queue
ENDIF
ENDFOR

From: dkl

We could create a queue table that has all of the columns/values of the key
value pairs that we send to IT. But if add/remove key/value pairs later on this
may be a hassle. We could just create a queue table with bug_id, it_id,
last_attempt_date, num_tries, data where data is a TEXT column with Data::Dumper
structure of the data we were trying to
send.

Dave