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.

Logged In: YES 
user_id=6405

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... 

Logged In: YES 
user_id=469548

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? 

Logged In: YES 
user_id=783085

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.

-roy

Logged In: YES 
user_id=6405

Sounds reasonable to me. 

Logged In: YES 
user_id=6405

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). 
 

Logged In: YES 
user_id=6405

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.

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 hyperdb.py 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/actions.py::_editnodes
         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/client.py 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.