Support

Home Forums Event Espresso Premium Event notifications resent after update

Event notifications resent after update

Posted: December 30, 2019 at 10:46 am


atrain

December 30, 2019 at 10:46 am

We do quarterly updates on our site. The last two updates of WP and the EE plugin have initiated a resend of email notifications. So all event registrations from the past were resent. Any ideas on this, if this cant be resolved the client wishes to find another event system. Due to the annoyance of every single event registration email being resent on updates.


Josh

  • Support Staff

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.


Josh

  • Support Staff

December 30, 2019 at 12:30 pm

One other thing to check is if you go to Event Espresso > Messages, does it show a record of messages being sent immediately after the update was done?


atrain

December 30, 2019 at 12:45 pm

All site email is sent using WP Mail SMTP via a separate email server. This is a regular ol wp install on a cpanel server wp chron works just as it should.

I went ahead and set the cleanup to 3 months

There are 250 emails sent on dec 24th, which is the day I did the updates on site. These are all the resends, I do not think they would have been in the queue since the emails were already sent. So I don’t think clearing the queue would help. Seems like EE is forgetting it sent the email so to speak upon update.


Josh

  • Support Staff

December 30, 2019 at 12:54 pm

Do you have a database backup from before you did the update on Dec 24?


atrain

December 30, 2019 at 12:58 pm

Yes what should I look for?


Josh

  • Support Staff

December 30, 2019 at 1:01 pm

You could look for messages in the Pending or failed to send queue.


atrain

December 30, 2019 at 1:11 pm

Not sure which table these are in, in the table _esp_message, it seems as if in october the database structure changed. All messages after oct are just null. What are the chances EE’s database structure changed but the plugin did not update it?

data: registration NULL NULL NULL NULL NULL 2


Tony

  • Support Staff

December 30, 2019 at 2:22 pm

We check each table before we use it and EE will throw a notice and attempt to fix any issues found automatically, so if we change the DB and somehow it wasn’t applied to your site on update (which tbh is unlikely) EE would either fix it on the next request or constantly throw notices telling you something is wrong and that it is trying to fix it.

data: registration NULL NULL NULL NULL NULL 2

That’s not all of the data but looks a lot like a message in the queue that is waiting for generation.

Here is an example of one from a test site:


4859
0
b14c2abcac7def66fd81983f37f539d5
0
email
registration
NULL
NULL
NULL
NULL
NULL
20
MIC

The ‘2’ above is likely from the default priority value of 20, the next column is STS_ID, what does that show for your above example?

Can you post the full row, please?


atrain

December 30, 2019 at 2:39 pm

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?

1800 0 220af8fcffc12f30a52158958356af0b 0 email registration NULL NULL NULL NULL NULL 20 MIC 2019-12-11 17:32:40 2019-12-11 17:32:40


Josh

  • Support Staff

December 30, 2019 at 2:56 pm

The row you posted is a message that wasn’t generated and wasn’t sent. It seems that after Oct 21 on your site wp_cron was disabled or the Event Espresso message cron tasks were deleted. When you update or reactivate EE it will check to see if all scheduled cron tasks are set up and if they’re not it will add them.

So if you had a bunch of messages with status ID MIC before you did the update, and after the update the cron tasks were restored/reactivated, then the software will try to process those. In other words, those exact messages were not sent before.

You can avoid this by first checking the Event Espresso > Messages page on your site before updating WP or EE. If there are any messages stuck in the queue you can either delete them or send them, then run the updates.


atrain

December 30, 2019 at 3:32 pm

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 admin person and the users received these messages for an event on november 14th over a month old. The person who monitors these got a ton of the admin notifications on the 24th so they immediately contacted me to tell me it happened again, that they got all the notifications at once again, and the users did to.


Josh

  • Support Staff

December 30, 2019 at 3:48 pm

After the transaction is processed and the message gets added to the queue it doesn’t have a MSG_context yet. For every one of the 70 rows there has the potential for multiple contexts: event admin, registrant, primary registrant. So 70 rows after generation could lead to 210 emails being sent.

You can verify the above with that messages table row that has TXN_ID 1800. You check the database backup (how many rows have TXN_ID 1800?) then compare the current database (how many rows have TXN_ID 1800?)


atrain

December 30, 2019 at 3:58 pm

No TXN_ID, the highest is 723. The live database does not have message ID 1800 anymore, assumed they get deleted? There is a gap from 1733 to 1801 on the live site, which corresponds to where those messages were saved in db before update. All the nulls were from 1733 to 1800


Josh

  • Support Staff

December 30, 2019 at 4:12 pm

My bad, the TXN_ID will be 0 for a message that hasn’t been generated yet. After the message is generated, there normally will be more than one message row for each message in the queue. In other words, if you have 70 rows in the database where their status hasn’t been generated yet, then once they do get generated (even if much later) there could be about 210 messages after they’re generated.


Tony

  • Support Staff

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.


atrain

December 31, 2019 at 2:22 pm

Thanks for the details. I agree that the update may have unstuck some old queued up messages. I need to monitor the site for a few months to see if any messages end back up in the queue and stuck before providing more details and trying to discover the issue. There seem to be none in the queue with the MIC status at the moment.

The support post ‘Event notifications resent after update’ is closed to new replies.

Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.

Support forum for Event Espresso 3 and Event Espresso 4.
Documentation for EE3 and EE4
Documentation for Event Espresso 3

Documentation for Event Espresso 4

Status: closed

Updated by  atrain 2 weeks, 6 days ago ago

Topic Tags

Notifications

This topic is:
pending
Do NOT follow this link or you will be banned from the site!