Another one that got hung up in my drafts folder. Same as the other, I think the basic coding probably is solved by now, but I'm worried we're not communicating about what the design problems are.
Aaryan Bhagat writes:
According to me, I think a new command which takes all the
Addressinstances and in each instances checks which tuple ofbounce_infohavedisabledattribute true. If it sees thedisabledattribute of a tuple to be true it will roughly:
- Send a warning
Shouldn't you first check if the disabled_warning_interval has been exceeded, and if it has, send a warning? Or is that what you mean by "check with the threshold" below?
- Increase warning counter
Incrementing the warning counter should always happen if the mail is successfully sent.
- Check with the threshold
What "threshold"? The disabled_warning_interval?
- Updates last_warning_sent timestamp value
Updated this timestamp should always happen if the mail is successfully sent.
I don't know offhand how any of the above operations could fail, and most likely to fail is sending mail, which is handled by the virgin, outgoing, and retry queues, not by the logic you're working on here. Still, perhaps some of the operations should be conditional on success. Also, you need to think about what happens if the warning fails for some address. Probably you just treat that as equivalent to a bounce in most cases, but what happens if it's a "no such address"? Is that already handled?
Note that adding to the virgin queue probably can't fail (except in really bad circumstances such as out of memory), but simply adding the message to the retry queue may not be appropriate (I forget how often that queue gets flushed).
If that doesn't make sense given what you know about how the queues work, then don't worry about it -- you probably know more about the queues than I do at this point.
The newly updated tuple ( with the updated counter and timestamp ) will be stored again.
I will add it to a cron job.
Cron job is what Mark suggested so that seems fine.
Steve