This looks sane to me. At least, after having stared at it for a few minutes, I can't come up with a good reason why it is going to cause things to horribly break.
-R Jared Johnson wrote: > > So, our fork has a few logging and bayes training mechanisms that run > in hook_reset_transaction. They are all very fast, most of the time; > but recently one of them broke and started running very slowly. The > result: QP would inject an incoming messages into the queue, enter > hook_reset_transaction, and 20 minutes later try to respond '250 > Queued!'. Of course, by then clients had given up and assumed their > messages were not delivered, resulting in duplicate messages and > bounces and such. > > Here's the patch that I applied to guard against this. On principal, > we should do as little as possible between queueing a message and > telling the client we queued; if a plugin really needs to something at > this juncture, it should probably be using hook_queue_post. Am I > right? Or is this going to break something and bite me later :) > > I haven't pushed this to my git yet, but I will if nobody points out > any fatal flaws or other reasons to change the patch first > > -Jared
