Roundup Tracker - Issues

Issue 2550784

classification
DetectorError in nosyreaction sending e-mail after upgrade to 1.4.20
Type: behavior Severity: minor
Components: Mail interface Versions: 1.4
process
Status: closed invalid
:
: : ber, jaraco, rouilj
Priority: :

Created on 2012-11-26 02:50 by jaraco, last changed 2016-07-05 07:12 by ber.

Messages
msg4685 Author: [hidden] (jaraco) Date: 2012-11-26 02:50
I run this tracker on Python 2.7.2. It runs well and stable against
roundup 1.4.19. When I upgrade to 1.4.20, however, many (but possibly
not all) updates to Issues fail. When they do, an error message appears
in the logs:

2012-11-25 20:40:06,536 ERROR Exception handling message
(Message-id='<030D763B-2273-4345-A197-563B01CFAC22@gmail.com>')
Traceback (most recent call last):
  File "C:\Program
Files\Python27\lib\site-packages\roundup-1.4.20-py2.7.egg\roundup\mailgw.py",
line 1476, in handle_Message
    return self.handle_message(message)
  File "C:\Program
Files\Python27\lib\site-packages\roundup-1.4.20-py2.7.egg\roundup\mailgw.py",
line 1541, in handle_message
    return self._handle_message(message)
  File "C:\Program
Files\Python27\lib\site-packages\roundup-1.4.20-py2.7.egg\roundup\mailgw.py",
line 1553, in _handle_message
    nodeid = self.parsed_message.parse ()
  File "C:\Program
Files\Python27\lib\site-packages\roundup-1.4.20-py2.7.egg\roundup\mailgw.py",
line 1230, in parse
    return self.create_node()
  File "C:\Program
Files\Python27\lib\site-packages\roundup-1.4.20-py2.7.egg\roundup\mailgw.py",
line 1147, in create_node
    self.cl.set(self.nodeid, **self.props)
  File "C:\Program
Files\Python27\lib\site-packages\roundup-1.4.20-py2.7.egg\roundup\backends\rdbms_common.py",
line 1715, in set
    self.fireReactors('set', nodeid, oldvalues)
  File "C:\Program
Files\Python27\lib\site-packages\roundup-1.4.20-py2.7.egg\roundup\hyperdb.py",
line 1265, in fireReactors
    react(self.db, self, nodeid, oldvalues)
  File "C:\Inetpub\Adams Row Tracker\detectors\nosyreaction.py", line
45, in nosyreaction
    raise roundupdb.DetectorError, message
DetectorError: Error: couldn't send email: {}

As you can see from the traceback, the error occurs when processing
incoming messages from the mail gateway. It also gets a similar error
when processing messages directly in the web UI (though I don't have a
copy of those tracebacks). Downgrading back to 1.4.19 makes the problem
go away, but I'd like to upgrade to 1.4.20.

The nosyreaction.py for this tracker is customized ever-so-slightly:

diff -r 9a71072c6f81 -r 5aac92f008ec _custom/detectors/nosyreaction.py
--- a/_custom/detectors/nosyreaction.py Thu Nov 22 08:57:43 2012 -0500
+++ b/_custom/detectors/nosyreaction.py Fri Oct 28 17:37:00 2011 +0000
@@ -40,7 +40,7 @@
     # send a copy of all new messages to the nosy list
     for msgid in determineNewMessages(cl, nodeid, oldvalues):
         try:
-            cl.nosymessage(nodeid, msgid, oldvalues)
+            cl.nosymessage(nodeid, msgid, oldvalues,
bcc_emails=['management@example.com'])
         except roundupdb.MessageSendError, message:
             raise roundupdb.DetectorError, message

That is the only change I've made to the tracker code itself. It simply
makes sure that all tracker notifications are blind-carbon-copied to the
'management' list.

Unfortunately, the error message isn't very useful (and empty dict) and
if I set e-mail to debug, the error doesn't occur (or at least I've been
unable to reproduce it). In general, I just have to try 1.4.20 and wait
until somebody complains. It's difficult to troubleshoot because I don't
want to turn off bcc_emails or send real e-mails from a test instance
(that will go to actual users).

Also, it seems that even while the bug exists, only some requests
encounter the error. I haven't yet figured out what factors are
necessary to trigger the error.

Is there any reason this approach should not work when upgrading to
1.4.20? Can you suggest ways to troubleshoot? Were there changes since
1.4.19 that might be implicated in a regression?
msg4687 Author: [hidden] (ber) Date: 2012-11-28 10:18
Hi Jason,
thanks for reporting the difference in behaviour 
between 1.4.19 and 1.4.20. 

Two ways I would try to analyse further:
a) get a hold of the message, this may be a bounce.
One way to do this would be to use the SENDMAILDEBUG environment
variable, see the docs. Compare the result emails for bcc for 1.4.19
and 1.4.20. 

b) you could try and check the code diffs between 1.4.19 and 1.4.20 
so see if there are potential changes that may change the behaviour
there
msg4708 Author: [hidden] (jaraco) Date: 2013-01-01 22:12
Thanks for the tips. I don't think e-mail debugging would work for me
because not all e-mails are failing; only some. In reviewing the code
base, I didn't see any substantial changes that happened around where
MessageSendErrors are generated.

In deciphering the string of the message, it appears there's only one
place in the code where that exception could have originated, namely,
mailer.py:287. So, against 1.4.21, I've added the following patch and
installed it:

diff -r d6e9f95cc30e roundup/mailer.py
--- a/roundup/mailer.py Fri Dec 21 15:06:23 2012 +0100
+++ b/roundup/mailer.py Tue Jan 01 17:09:51 2013 -0500
@@ -284,6 +284,9 @@
                 raise MessageSendError("Error: couldn't send email: "
                                        "mailhost %s"%value)
             except smtplib.SMTPException, msg:
+                with open(r'c:\inetpub\Adams Row
Tracker\exception.txt', 'a') as file:
+                    traceback.print_exc(file=file)
+                    file.write('\n')
                 raise MessageSendError("Error: couldn't send email:
%s"%msg)

 class SMTPConnection(smtplib.SMTP):

My hope is that diff will provide access to the underlying error that's
masked by the MessageSendError if it occurs again. I'll report back if I
find something.
msg4710 Author: [hidden] (ber) Date: 2013-01-02 11:45
Cool, let us know.
(Email debugging could still potentially help because it may be the email
system that is rejecting some emails.)
msg4716 Author: [hidden] (jaraco) Date: 2013-01-04 14:24
After running for most of a week with 1.4.21 (as patched), the server
has not yet encountered the error. This suggests to me that the issue
was transient (perhaps due to latent values in the session), was fixed
between 1.4.20 and 1.4.21, or is infrequent enough that I haven't
encountered it yet.

The good news is that the site is operational on 1.4.21. I'll continue
to monitor the situation in case the errors arise again.
msg4718 Author: [hidden] (ber) Date: 2013-01-04 19:16
Jason,
good news, thanks for the follow up!
msg4821 Author: [hidden] (jaraco) Date: 2013-03-09 17:13
It seems I may have improperly installed the patched version of 1.4.21,
so my tests have been inadequate. I see now that due to conflicting
installs, the '1.4.21' release was not actually active and 1.4.19 was
still being used. I need to go back and install the troubleshooting code
again and make sure I have the proper version active.
msg5645 Author: [hidden] (rouilj) Date: 2016-06-27 01:01
Jason did you ever figure out what happened here?

Do we have a bug to address?
msg5698 Author: [hidden] (jaraco) Date: 2016-07-01 15:21
Unfortunately, not to long after my last report, we decommissioned the
tracker, so I no longer have any data on the issue and will be unlikely
to ever encounter it again. I suggest then that this issue be marked as
invalid or wontfix. Thanks.
msg5700 Author: [hidden] (rouilj) Date: 2016-07-01 21:13
Jason thanks for the followup email. Sorry we took so long to close it
that you had to stop using roundup.

-- rouilj
msg5735 Author: [hidden] (ber) Date: 2016-07-04 07:45
Hi Jason,
what was the reason you decomissioned the tracker?
(Or what would roundup have to change that you would consider it again?)
Best,
Bernhard
msg5740 Author: [hidden] (jaraco) Date: 2016-07-04 15:19
The reason was internal - our condo board was using it to manage
property issues, but the association wanted less transparency and
documentation of issues, so decided to mothball the site. Roundup was
actually pretty powerful, allowing for centralized tracking of issues
and attachment of photos and other assets. The ability to automatically
BCC the management for each issue was a crucial feature and quite
powerful. I'd recommend it to others wanting to do the same.
msg5755 Author: [hidden] (ber) Date: 2016-07-05 07:12
Jason,
thanks for you feedback!
History
Date User Action Args
2016-07-05 07:12:24bersetmessages: + msg5755
2016-07-04 15:19:28jaracosetmessages: + msg5740
2016-07-04 07:45:19bersetmessages: + msg5735
2016-07-01 21:13:45rouiljsetstatus: new -> closed
resolution: remind -> invalid
messages: + msg5700
2016-07-01 15:21:48jaracosetmessages: + msg5698
2016-06-27 01:01:30rouiljsetresolution: remind
messages: + msg5645
nosy: + rouilj
2013-03-09 17:13:52jaracosetmessages: + msg4821
2013-01-04 19:16:26bersetmessages: + msg4718
2013-01-04 14:24:50jaracosetmessages: + msg4716
severity: urgent -> minor
2013-01-02 11:45:14bersetmessages: + msg4710
2013-01-01 22:12:42jaracosetmessages: + msg4708
2012-11-28 10:18:30bersetnosy: + ber
messages: + msg4687
2012-11-26 02:50:04jaracocreate