Roundup Tracker - Issues

Issue 859291

Title: Issue Update Fails when SMTP Server Fails
Type: rfe Severity: normal
Components: None Versions:
Status: open Resolution:
Dependencies: Superseder:
Assigned To: richard Nosy List: jlgijsbers, richard, rouilj, roysrapoport
Priority: normal Keywords:

Created on 2003-12-13 01:34 by anonymous, last changed 2016-07-04 19:56 by rouilj.

msg3278 Author: [hidden] (anonymous) Date: 2003-12-13 01:34
When the SMTP server configured for a tracker's use
refuses email (say, with a 400-type error), Roundup
throws an exception and does not update the issue.
msg3279 Author: [hidden] (richard) Date: 2004-01-17 02:49
Logged In: YES 

I guess the best solution here would be to allow configuration of 
using a local sendmail / similar queueing mechanism. 
Other than that, the idea of having Roundup doing mail 
queueing of its own is ... eugh. 
Not sure whether there's any other solution... 
msg3280 Author: [hidden] (jlgijsbers) Date: 2004-01-18 05:44
Logged In: YES 

How about just adding a nicer warning message telling the
user no mail was sent and that he should send mail manually
to everyone on the nosy list, but updating the issue anyway? 
msg3281 Author: [hidden] (roysrapoport) Date: 2004-01-18 05:49
Logged In: YES 

FWIW, I think it'd be perfectly OK to just fail to send the
message, let the user know the message wasn't sent, but
update the issue -- in other words, I'm in agreement with
Mr. Gijsbers.

msg3282 Author: [hidden] (richard) Date: 2004-01-18 08:12
Logged In: YES 

Sounds reasonable to me. 
msg3283 Author: [hidden] (richard) Date: 2004-02-26 23:57
Logged In: YES 

To implement this kind of thing, we really need to be able to 
raise non-fatal exceptions in Roundup code that should result 
in a message being displayed to the user, but normal change 
committing be unaffected (ie. the three existing top-level db 
open / commit handlers would need to cope with it, as would 
anyone writing a stand-alone script). 
msg3284 Author: [hidden] (richard) Date: 2005-01-04 01:53
Logged In: YES 

I'm going to change this to be a feature request, as it's not strictly a bug, 
and it'll be somewhat icky to implement.
msg5744 Author: [hidden] (rouilj) Date: 2016-07-04 19:56
I took a look through the code and I wonder if this would work:

  have reactors optionally return an array of tuples:
     (exception, message)

in change:

   the call to:
     react(self.db, self, nodeid, oldvalues)
   to capture those tuples and store in:
   self.warning_exceptions[] where self is <hyperdb.Class "issue">
   that same object is created at cgi/
         before calling into rdbms_common (or back_anydbm I think)
   it looks like _editnodes can add info that gets sent back to the user.

I am not sure if adding a new prop into the issue is advisable. Seems
like it could be a hack.

It looks like cgi/ is set up to handle a MessageError and
report that to the user as an error. However as Richard said raising
MessageError will stop any further reactors from firing.

Too bad there isn't a queuing mechanism for exceptions where they
could be shoved in a queue (along with an id indicating that function
added the exception). Then they could be processed asynchronously by a
handler in a calling function at a higher level in the stack.

Kind of a soft exception that doesn't force the callee to return
immediately. Which may be what what richard was hinting at.

Also to test this just set the port number for smtp server in
config.ini to an unused port. Then send a message that triggers the
nosyreactor reactor.
Date User Action Args
2016-07-04 19:56:51rouiljsetnosy: + rouilj
messages: + msg5744
2003-12-13 01:34:27anonymouscreate