Issue 2550784
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:24 | ber | set | messages: + msg5755 |
2016-07-04 15:19:28 | jaraco | set | messages: + msg5740 |
2016-07-04 07:45:19 | ber | set | messages: + msg5735 |
2016-07-01 21:13:45 | rouilj | set | status: new -> closed resolution: remind -> invalid messages: + msg5700 |
2016-07-01 15:21:48 | jaraco | set | messages: + msg5698 |
2016-06-27 01:01:30 | rouilj | set | resolution: remind messages: + msg5645 nosy: + rouilj |
2013-03-09 17:13:52 | jaraco | set | messages: + msg4821 |
2013-01-04 19:16:26 | ber | set | messages: + msg4718 |
2013-01-04 14:24:50 | jaraco | set | messages:
+ msg4716 severity: urgent -> minor |
2013-01-02 11:45:14 | ber | set | messages: + msg4710 |
2013-01-01 22:12:42 | jaraco | set | messages: + msg4708 |
2012-11-28 10:18:30 | ber | set | nosy:
+ ber messages: + msg4687 |
2012-11-26 02:50:04 | jaraco | create |