" Merge failed. Couldn't set Status" - after upgrade to 3.4.5

We noticed a bug with RT 3.4.5 after our upgrade, which could be an
indicator of an “inconsistent database”.

When we attempted to merge one ticket into another we go this message
"Merge failed. Couldn’t set Status"

It turns out that both of the tickets were already set to “resolved”.
After we switched the status to “open” we were able to merge the tickets
(then we switched the merged ticket back to resolved).

We verified that our accounts have “ModifyTicket” rights and also
checked tried this as root.

Looking at our rt.log file we saw this message:
[Wed May 31 17:45:01 2006] [error]: RT::Ticket=HASH(0xa70c0ec) couldn’t
set status to resolved. RT’s Database may be inconsistent.
(/usr/local/rt3/lib/RT/Ticket_Overlay.pm:2730)

When I tested on our old box (RT 3.2.2), merging resolved tickets wasn’t
a problem.

Any one else experiencing this or have suggestions on what I can do
about it?

I migrated from:
FreeBSD 4.11, RT 3.2.2, MySQL 4.1.7, Apache 1.3.33, Perl 5.8.4,
mod_perl-1.29, DBI-1.42_1
–TO–>
RHEL 4.3, RT 3.4.5, MySQL 4.1.2-3, Apache 2.0.52, Perl 5.8.5,
mod_fastcgi-2.4.2, DBI-1.40-8

Thanks,
Mike

Mike Patterson
Systems Manager
UC Berkeley Extension

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We noticed a bug with RT 3.4.5 after our upgrade, which could be an
indicator of an “inconsistent database”.

When we attempted to merge one ticket into another we go this message
"Merge failed. Couldn’t set Status"

It turns out that both of the tickets were already set to “resolved”.
After we switched the status to “open” we were able to merge the tickets
(then we switched the merged ticket back to resolved).

I have noticed this on 3.4.2 as well. I’ve written a perl script (using
the RT API) that allows merging two tickets from the command line (I don’t
like using the supplied ‘rt’ CLI command). When I got the above error
message, I looked into the RT code and found that a ticket to be merged
into another is first changed to ‘resolved’ status (I don’t know why).
If the status is already ‘resolved’, this results in an error message.

I don't know why setting a status to the same value that's currently set should be considered an error; this has been a problem for me in other script-writing contexts, where I always have to check for this case before invoking the SetStatus method, lest I get a spurious error code. But I think this is really part of a broader problem of how error codes are set in RT API methods (i.e., any error just returns 0, so a script can't tell what kind of error it was).

So, my merge script now has to check first if the status is ‘resolved’;
if so, set it to ‘open’ and then merge it. If the merge fails for some
reason, I set the status back to ‘resolved’, but only if that’s what it
was originally.

I can see how this problem can be quite annoying when using the Web UI,
since it means an additional manual step of ‘unresolving’ the ticket
first, as you’ve discovered.

We verified that our accounts have “ModifyTicket” rights and also
checked tried this as root.

I don’t believe this has anything to do with rights. For some reason, RT
just decides to set status to ‘resolved’ as part of the merge process.

When I tested on our old box (RT 3.2.2), merging resolved tickets wasn’t
a problem.

I guess this started with some version after 3.2.2!

Mike

Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRH8Lza0bf1iNr4mCEQKGKwCgveuY50TlGQN4xcMIfNz2FZc36pMAoLWS
FJLeW/A/Fxi2xLfJqNHyuTXs
=Izfa
-----END PGP SIGNATURE-----

Mike Patterson wrote:

We noticed a bug with RT 3.4.5 after our upgrade, which could be an
indicator of an “inconsistent database”.

When we attempted to merge one ticket into another we go this message
"Merge failed. Couldn’t set Status"

It turns out that both of the tickets were already set to “resolved”.
After we switched the status to “open” we were able to merge the
tickets (then we switched the merged ticket back to resolved).

We verified that our accounts have “ModifyTicket” rights and also
checked tried this as root.

Looking at our rt.log file we saw this message:
[Wed May 31 17:45:01 2006] [error]: RT::Ticket=HASH(0xa70c0ec)
couldn’t set status to resolved. RT’s Database may be inconsistent.
(/usr/local/rt3/lib/RT/Ticket_Overlay.pm:2730)

When I tested on our old box (RT 3.2.2), merging resolved tickets
wasn’t a problem.

Any one else experiencing this or have suggestions on what I can do
about it?

I migrated from:
FreeBSD 4.11, RT 3.2.2, MySQL 4.1.7, Apache 1.3.33, Perl 5.8.4,
mod_perl-1.29, DBI-1.42_1
–TO–>
RHEL 4.3, RT 3.4.5, MySQL 4.1.2-3, Apache 2.0.52, Perl 5.8.5,
mod_fastcgi-2.4.2, DBI-1.40-8

Thanks,
Mike

Mike,

To be honest, I can't see that as a problem. I thought the whole 

point of merging tickets was to get one owner to work on similar (or
same) problems on one ticket instead of several, therefore, you merge
the tickets . before they get resolved. However, everyone does their
thing differently. I like the setup. That way it acts like a filter to
keep from merging tickets that are already resolved. you know, the cat
is already out of the bag, no sense closing it.

Kenn