Handling message send failures
| Project: | Messaging |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Hi,
I've been using your excellent Messaging framework in order to manage queuing of a bulk mail.
I have one question about the way you handle errors. At the moment you seem to just record them in the log, but leave no indication that the mail wasn't sent - so if I look at the log, I assume that all is fine. Am I missing something here?
I've made a small ammendment to my version that uses the sent field to determine that there was a problem. If this field is empty and doesn't show as queued - then I assume there was a problem.
I made a small change to messaging_store_sent to accept a new parameter called $failed, and then created a variable called $senttime that determines whether a time should be recorded.
function messaging_store_sent($mqid, $log = FALSE, $failed = FALSE) {
$mqid = is_array($mqid) ? $mqid : array($mqid);
list($where, $args) = messaging_store_query(array('mqid' => $mqid));
// First delete the ones that are not for logging
if (!$log) {
db_query("DELETE FROM {messaging_store} WHERE log = 0 AND ".implode(' AND ', $where) , $mqid);
}
// Now mark the rest as sent
$senttime = $failed ? 0 : time();
$args = array_merge(array($senttime), $mqid);
db_query("UPDATE {messaging_store} SET queue = 0, log = 1, sent = %d WHERE ".implode(' AND ', $where), $args);
}I've obviously also amended the function call in function messaging_store_queue_process_step:
if ($unsent) {
messaging_store_sent($unsent, TRUE, TRUE);
}Please let me know if this is useful?
Thanks,
Dan
#1
Alternativelly, it would be better to add an extra field to the store that flags error=1 or 0. It might be useful to know when the message was being sent so you can track the actual error message in the log.
#2
Yes, this makes a lot of sense, better the second option (error field).
I think maybe even better, an error or status code, like 0 = none, 1 = unknown, 2 = invalid destination, ....
Need to think about it, more ideas welcomed.
#3
Nice idea to have standard error numbers, but I feel you may get lost trying to define all possible errors from the many sub messaging modules. You may find it easier just to implement true or false (1 or 0).
To extend this you might want to add an extra field that records any error messages returned by send modules.