[1] This changes things so that KeyboardInterrupt will not cause the currently underway message to be lost. Instead it is left in the mailbox and can be retried next time.
[2] If MemoryError occurs while processing a message, there are a few possibilities: - if the process is able to continue, this code will log an oops, send an error to the submitting user, and delete the message. If the error was somewhat deterministic from the original request, that seems reasonable to me. - if the process is not able to free enough memory to run error handling, it will probably get a knock-on memory error and terminate, either before or after logging the oops. the message should not be lost. this probably needs to be handled at a different level. - if garbage accumulates in memory so that we run out in a way that's not especially related to the message underway, we may end up oopsing and rejecting a lot of messages blamelessly. I think this is all tolerably similar to what happens with web requests, and we should have the messages in the librarian so if we really wanted, we could replay them. [3] I agree using asserts to check for user input error is ugly, but I'm reluctant to increase the scope of this patch beyond just making this code more tractable. If this lands safely I may try to do more. -- https://code.launchpad.net/~mbp/launchpad/mail-cleanup/+merge/58867 Your team Launchpad Community Development Team is requested to review the proposed merge of lp:~mbp/launchpad/mail-cleanup into lp:launchpad. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
