[Rt-devel] rt-mailgate issue: Empty Tickets created if Attachment insert fails

Andrés Schiavo andresschiavo at gmail.com
Fri Jul 9 09:28:10 EDT 2010


Hello Ruslan, thanks for response

this patch alone does not fix the issue.
The last post was too long and I've preferred to split my solution for the
issue into several messages.
I need to change this line in Transaction_Overlay.pm

--- Transaction_Overlay.pm.orig 2010-07-09 14:45:52.000000000 +0200
+++ Transaction_Overlay.pm      2010-07-09 14:46:32.000000000 +0200
@@ -513,11 +513,11 @@
     my $Attachment = RT::Attachment->new( $self->CurrentUser );
     my ($id, $msg) = $Attachment->Create(
         TransactionId => $self->Id,
         Attachment    => $MIMEObject
     );
-    return ( $Attachment, $msg || $self->loc("Attachment created") );
+    return ( $id, $msg || $self->loc("Attachment created") );
 }

 # }}}

 # }}}


And finally this ugly patch to rt-mailgate, I hope someone with higher
skills in perl/mason could make something better with the returned status.

--- rt-mailgate.orig    2010-07-09 14:57:49.000000000 +0200
+++ rt-mailgate 2010-07-09 15:18:27.000000000 +0200
@@ -61,6 +61,7 @@
 $DYNAMIC_FILE_UPLOAD = 1;

 use constant EX_TEMPFAIL => 75;
+use constant EX_UNKNOWERR => 76;
 use constant BUFFER_SIZE => 8192;

 my %opts;
@@ -131,7 +132,18 @@
 my $content = $r->content;
 print STDERR $content ."\n" if $opts{'debug'};

-if ( $content !~ /^(ok|not ok)/ ) {
+if ( $content !~ /^(ok)/ ) {
+
+    # Ticket could not be created for unknow reason.
+    # Return non zero to avoid that fetchmail clear email from mail server.
+    print STDERR <<EOF;
+RT server error.
+
+The RT server sends an unexpected error.
+EOF
+
+    exit EX_UNKNOWERR;
+} elsif ( $content !~ /^(not ok)/ ) {

     # It's not the server's fault if the mail is bogus. We just want to
know that
     # *something* came out of the server.
@@ -145,10 +157,10 @@
 EOF

     exit EX_TEMPFAIL;
+} else {
+    exit;
 }

-exit;
-
 END {
     unlink $message{'filename'} if $message{'filename'};
 }

I hope those patches fix the issue and don't break anything else
Andrés.


2010/7/9 Ruslan Zakirov <ruz at bestpractical.com>

> Hello Andres,
>
> As I understand the following change will fix the issue for you. If it
> does then drop me a note and I'll push it into core. If it doesn't
> then we should investigate more. Don't forget to restart the web
> server after patching.
>
> I think it's a bug. We can not guaranty that everything will work
> perfectly when you're out of space on disks, but this patch should
> bring more sanity.
>
> diff --git a/lib/RT/Attachment_Overlay.pm b/lib/RT/Attachment_Overlay.pm
> index e3c1b9c..8c60185 100644
> --- a/lib/RT/Attachment_Overlay.pm
> +++ b/lib/RT/Attachment_Overlay.pm
> @@ -154,6 +154,7 @@ sub Create {
>
>         unless ($id) {
>             $RT::Logger->crit("Attachment insert failed - ".
> $RT::Handle->dbh->errstr);
> +            return ($id);
>         }
>
>          foreach my $part ( $Attachment->parts ) {
> @@ -165,6 +166,7 @@ sub Create {
>              );
>             unless ($id) {
>                 $RT::Logger->crit("Attachment insert failed: ".
> $RT::Handle->dbh->errstr);
> +                return ($id);
>             }
>         }
>          return ($id);
>
>
> On Fri, Jul 9, 2010 at 1:55 PM, Andrés Schiavo <andresschiavo at gmail.com>
> wrote:
> > Hi, I'm currently working with a RT 3 instance and I've found that some
> > Tickets could be created with missing content under specific situations.
> > This is my scenario:
> > * RT 3.8.7 runnig on RHEL5 with perl 5.8.8
> > * Oracle 10g database
> > * External mail server and fetchmail to recover emails
> > This RT instance is quite special, we recive a lot of spam (we are
> working
> > to fix it) and the database grows quickly. During working days our
> > monitoring agents alert us about reaching  database space limit, but if
> this
> > happen on weekend, nobody extends de DB until Monday.
> > Because of Spam we have configured fetchmail with "no keep" option, so if
> > Ticket creation fails and fetchmail does not recieve an error return code
> > the information of the email is lost.
> > I know that this are a lot of "special situations" but I think that
> > rt-mailgate should return non zero result when RT couldn't create the
> Ticket
> > correctly.
> > I haven't try to reproduce with other databases than Oracle, but I've
> > reproduce this behavior on two different Oracle instances
> > This are the steps to reproduce the issue:
> > When rt database tablesapce is full, fetchmail try to recover an email
> (with
> > an attachment or an html email).
> > Ticket is created but we end up with no attach or no text if email was
> html.
> > Fetchmail recive a 0 ret code and erase email from server.
> > I've attach the rt log when attachment insert fails.
> > I don't know if this is a bug or that's the way it's supposed to work,
> but
> > we can't loose the email information.
> > If this is a bug, I think that could be generated by the scope of the
> > variable $id in this code (Attachment_Overlay line 140)
> >     # If a message has no bodyhandle, that means that it has subparts (or
> > appears to)
> >     # and we should act accordingly.
> >     unless ( defined $Attachment->bodyhandle ) {
> >         my ($id) = $self->SUPER::Create(
> >             TransactionId => $args{'TransactionId'},
> >             Parent        => $args{'Parent'},
> >             ContentType   => $Attachment->mime_type,
> >             Headers       => $head,
> >             MessageId     => $MessageId,
> >             Subject       => $Subject,
> >         );
> >         unless ($id) {
> >             $RT::Logger->crit("Attachment insert failed - ".
> > $RT::Handle->dbh->errstr);
> >         }
> >         foreach my $part ( $Attachment->parts ) {
> >             my $SubAttachment = new RT::Attachment( $self->CurrentUser );
> >             my ($id) = $SubAttachment->Create(
> >                 TransactionId => $args{'TransactionId'},
> >                 Parent        => $id,
> >                 Attachment    => $part,
> >             );
> >             unless ($id) {
> >                 $RT::Logger->crit("Attachment insert failed: ".
> > $RT::Handle->dbh->errstr);
> >             }
> >         }
> >         return ($id);
> >     }
> >     #If it's not multipart
> >     else {
> >         my ($ContentEncoding, $Body) = $self->_EncodeLOB(
> >             $Attachment->bodyhandle->as_string,
> >
> > If the first SUPER::Create is successfull, the $id value isn't undef, but
> > within the foreach loop, if an error ocurred adding Subattachments the
> crit
> > message is printed because the inner $id is undef, but the returned value
> is
> > the outer $id that is not undef, so the Ticket is created despite the
> error
> > adding a subattachment. Adding a return($id) inside the foreach loop
> solves
> > the problem an RT knows that Ticket can not be completly created.
> > This post is too long and don't want to add more info (specially with
> this
> > terrible bad english), but despite the error returned to rt-mailgate when
> > Ticket creation fails, it tells fetchmail that everything is ok and email
> is
> > deleted. I've made an ugly hack to make it work, but I think that
> > check_for_failure() in rt-mailgate could get te correct return code, I'm
> not
> > a perl expert and couldn't make it work, any help?
> > Anyway, do you think that this is a bug or a feature?
> > Best regards.
> > Andres.
>
>
>
> --
> Best regards, Ruslan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-devel/attachments/20100709/fcdef03a/attachment-0001.html>


More information about the rt-devel mailing list