← Back to team overview

randgen team mailing list archive

Re: Better/mode detailed STATUS reporting

 

Hi Roel,


Please see below for comments.

On 08/26/2014 10:50 PM, Roel Van de Paar wrote:
Hi All,

Hope you're all well.

This is just a little heads up that we're considering a patch to RQG.

Problem description: as you know, various statuses returned by RQG are
very non-descriptive. For example, when STATUS_DATABASE_CORRUPTION
is triggered, it could be due to one of the 7 mapped error codes from
MySQL.pm,
or it could just as well be from the error message corruption validator.

Consider other often unclear statuses like STATUS_ENVIRONMENT_FAILURE,
PERL_FAILURE, UNKNOWN_ERROR, INTERNAL_ERROR, etc. (check MySQL.pm
for more examples.)

The reason is that RQG usually maps many different MySQL errors to a single
STATUS code, and when returning that STATUS code it at times fails to
explain
what the underlying reason is. Even knowing the error code which
triggered a given
STATUS in a multi-threaded run would be very beneficial (there is no
clear way
to see this in the logs atm, and it requires wading through the logs).

But as you can see from the STATUS_DATABASE_CORRUPTION example;
things are not as clear as simply checking for an error code - the
STATUS can
also be returned from transformers, validators, reporters.

Proposal: The plan we're considering is to modify the status code return
to return two
or more values. All of the places that check that return code will need
to be modified
to handle returning an array instead of a single value. We can do this.

This is invasive, but if all of the transformers / validators / etc.
could return a sort
of "extended status" it would end up being very flexible and potentially
useful for
lots of other things.

Benefits: clarity when it comes to any STATUS!

Risk: this may temporarily unsettle the code a bit, but we will test
things well
internally before roll out.

Thoughts?


I understand the issue, and agree that it in some scenarios would be nice to be able to tell the root cause of a certain end status more easily.

Maybe it would be helpful for RQG users if you provide some examples of how this would look, when ready?

Before merging with the trunk, the details of how the output will be changed must be clearly specified (IMHO), as people may have tools etc. which depend on the current status reporting in some way.

Also, will the return value from the RQG runner still be the original status (e.g. STATUS_DATABSE_CORRUPTION == 105)?


thanks,

--
John



References