Support

December 30, 2019 at 12:29 pm

Hi,

It sounds like there are messages that are getting stuck in the queue. Are you using the web server’s email server or are you using a third party email server like Mandrill or SendInBlue? Also, do you know if there’s an alternative to wp_cron set up or does the site just use the normal wp_cron function? In any case, you can go to Event Espresso > Messages, then delete any messages stored in the queue.

Also, you can go to Event Espresso > Messages > Settings and set the setting Cleanup of old messages: to 3 months, which will removed the older messages stored in the database. If they’re not stored they cannot be resent.

December 30, 2019 at 4:50 pm

There’s a little bit of confusion above, so first let’s add some details to your _wp_message row so it’s a little easier to follow and we all refer to the same values:

MSG_ID => 1800
GRP_ID => 0
MSG_Token => 220af8fcffc12f30a52158958356af0b
TXN_ID => 0
MSG_messenger => email
MSG_mesage_type => registration
MSG_context => NULL
MSG_recipient_ID => NULL
MSG_recipient_type => NULL
MSG_content => ”
MSG_to => NULL
MSG_from => NULL
MSG_subject => ”
MSG_prioirty => 20
STS_ID => MIC
MSG_created => 2019-12-11 17:32:40
MSG_modified => 2019-12-11 17:32:40

Some rows are empty so don’t show up in your example, I’ve padded them above.

1800 isn’t the TXN_ID here, it’s the ID of this message row (MSG_ID), as the message hasn’t been generated it has no TXN_ID yet (nothing has been generated, this row can be considered as nothing more than a placeholder at this point).

There were only about 70 of these in there with MIC status. There were about 250 resends on the 24th. I still don’t think these were cued up messages, they seem to be resends. On the live site the status is MSN for all of these now.

The fact those 70 rows are now showing MSN (MESSAGE_STATUS_SENT) means that each of those queued for generation rows has been generated (which, as Josh mentioned can produce more than 70 emails), queued for sending and then sent.

(Just to add some additional info, a status of ‘MIC’ MESSAGE_INCOMPLETE, meaning the messages has been added and queued for generation)

Registration Approved messages (which I assume most of these are) will generate a minimum of 2 contexts by default, so if we say all of those are Reg Approved emails, that’s a minimum of 140 emails. Group emails will trigger 2+n emails (Event Admin, Primary Registrant (as the registrant context) + any additional registrations) meaning some of those single rows can be 3 or more emails.

Point being that just because there are 70 rows here doesn’t mean you’ll get 70 emails, you’ll certainly see more in the queue than 70 from those.

The live database does not have message ID 1800 anymore, assumed they get deleted?

Correct, a MIC message row will be ‘used’ (although not really, it’s a little easier to follow) to generate the messages related to it, which is where all the contexts mentioned above come into it. 1800 will be replaced at least 2 additional rows that have generated content will be added.

So 1800 was your last message row on before the update, what is the highest current MSG_ID on the live site? The difference between gives you a better idea of how many messages were actually generated and sent from the above group (give or take any registrations that triggered emails between now and then).

This question should be answered as it is important:

Whole row. This is the last entry, and it’s dec 11th. Everything before oct 21st contains email addresses, subjects, etc. So where are the newer messages stored, or is it failing?

Nothing has ‘changed’ in the DB there, the difference is just that the messages before oct 21st appear to have been generated yet everything after that has not. The NULLS are valid, they are expected for messages that are queued for generation (although them sitting in the queue for generation for so long is not).

The problem appears to be that messages stopped generating from oct 21st onwards.

That row was timestamped for 2019-12-11, meaning it’s been sitting in the queue way before you did the update. The updated basically refreshed the cron jobs which meant emails started generating and sending, it all looks like a backlog rather than a resend

—

Are you 100% certain the ‘original’ emails sent? I can’t see how when they are sitting in in the queue to generate, meaning they don’t actually know where they are sending yet (note how MSG_to is NULL).

—

Note that we are not saying there isn’t an issue here and we are investigating, however, EE working through a backlog of queued for generation emails is a totally separate issue from EE regenerating all the emails from scratch (I can’t see how that would be possible tbh) so we are just trying to narrow down what actually happened a little.