Throttle not enforced; error in logs, “A non-numeric value encountered”

I put in a workaround, which has suppressed the error and hopefully is also the correct logical handling of the condition.

$ diff wp-content/plugins/wp-mailster/mailster/mail/MailSender.php wp-content/plugins/wp-mailster/mailster/mail/MailSender.php_bak_12_1_2020_1
182,184d181
<                                       if(is_null($lastMailSentAt)) {
<                                               $lastMailSentAt = time();
<                                       }

While the error is gone, unfortunately, the throttling still isn’t working.
My suspicion is whatever is causing the $lastMailSentAt to be null is also causing some other important variables also to be null.

This is a logic error in the code.
It basically means that as long as the time since last e-mail is at least the configurable amount of time between two e-mails, it will try to send again.
This is incorrect behavior. It needs another conditional via && to represent whether or not the $timeDiffSinceLastMail is at least an hour, since we are in throttle mode by this point.

Hmmm. Whether the hosting provider resets at the top of the hour or on a rolling 60-minutes will vary. Always waiting 60-minutes would be the safest posture for all hosting providers, even though it may result in slower sending for some providers (if they reset at top of hour).

My hosting provider appears to operate on a rolling 60-minute window.

if(($timeDiffSinceLastMail >= $waitBetweenTwoMails) || ($timeDiffSinceLastMail < 0) || ($lastMailSentAt < 0)){
     $log->debug('"Wait between Two Mails" Throttling -> Time diff since last mail is '.$timeDiffSinceLastMail.' seconds, enough, therefore proceed...');

One thing I cannot explain after working around the null $lastMailSentAt is how would setting $lastMailSentAt to time() and then subtracting time() from time() yield such a high number? Should be 0 or close to 0. :-/

Referring to these logs:

2020-12-01 17:36:08 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844168 seconds, enough, therefore proceed...
2020-12-01 17:36:08 DEBU "Wait between Two Mails" Throttling Active, setting: 10 seconds
2020-12-01 17:36:08 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844168 seconds, enough, therefore proceed...
2020-12-01 17:36:09 DEBU "Wait between Two Mails" Throttling Active, setting: 10 seconds
2020-12-01 17:36:09 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844169 seconds, enough, therefore proceed...
2020-12-01 17:36:09 DEBU "Wait between Two Mails" Throttling Active, setting: 10 seconds
2020-12-01 17:36:09 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844169 seconds, enough, therefore proceed...
2020-12-01 17:36:10 DEBU "Wait between Two Mails" Throttling Active, setting: 10 seconds
2020-12-01 17:36:10 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844170 seconds, enough, therefore proceed...
2020-12-01 17:36:10 DEBU "Wait between Two Mails" Throttling Active, setting: 10 seconds
2020-12-01 17:36:10 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844170 seconds, enough, therefore proceed...
2020-12-01 17:36:11 DEBU "Wait between Two Mails" Throttling Active, setting: 10 seconds
2020-12-01 17:36:11 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844171 seconds, enough, therefore proceed...
2020-12-01 17:36:11 DEBU "Wait between Two Mails" Throttling Active, setting: 10 seconds
2020-12-01 17:36:11 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844171 seconds, enough, therefore proceed...
2020-12-01 17:36:11 DEBU "Wait between Two Mails" Throttling Active, setting: 10 seconds
2020-12-01 17:36:11 DEBU "Wait between Two Mails" Throttling -> Time diff since last mail is 1606844171 seconds, enough, therefore proceed...

Also, notice that it isn’t really waiting 10 seconds. FAKE NEWS. ??

I appreciate the effort you are putting into debugging this.

The thing that looks fishy to me is the fact that $lastMailSentAt is null. In theory, this never should be the case but at some point the value got in like that and that is why your installation has the problem.
This edge case needs to be addressed. I have released v1.6.16 that adds some logic here.

About the log: yes, it is not waiting 10 seconds because you are in the execution path where it considers enough time to have passed (that is what “enough, therefore proceed…” means).
And the fact that you end up in that exuection path is releated to the null value.

So give v1.6.16 a shot and send the log if needed.
Thanks.

Oh, and: the very clear message of your hoster may be clear for you – however that is something which is non standardized. So each hoster can write in the error message what they want and change it anytime.
So easy for a human to interpret, but not good for catching with code.

Thanks, I’ll try it immediately.
This will be my first time updating the paid version, so I presume it’s out there in my “account” area where I originally made the purchase?

• This reply was modified 4 years, 3 months ago by aetherscythe.

About parsing the limit message, let me define a regex at the server level and you can check it based on the regex.

Hi, Holger.
I found the update mechanism. Well done.
Way easier than updating any other paid plugin.

@brandtoss the update with the bug-fix appears to have completely resolved this issue. Would still like to see an option to detect when the SMTP server is rejecting messages. Please add an option to set a regex pattern on the mail server to cover this condition and if the message back from the SMTP server matches the regex, then throttle for a configurable amount of time taken also from another property set at the SMTP server level.

Described edge case fixed in v1.6.16