Support » Plugin: WP Mailster » Throttle not enforced; error in logs, “A non-numeric value encountered”

  • Resolved aetherscythe

    (@aetherscythe)


    Holger,

    Mail got stuck last night because the throttle was not enforced.

    This may be the reason…
    For some reason the code couldn’t determine the last time mail was sent.

    
    [30-Nov-2020 14:07:01 UTC] PHP Warning:  A non-numeric value encountered in /home/customer/www/example.com/public_html/wp-content/plugins/wp-mailster/mailster/mail/MailSender.php on line 182
    

    Which is…

    
    $timeDiffSinceLastMail = (time() - $lastMailSentAt);
    

    Also, my host is sending a very clear message about the throttling.
    It would be good if you could parse the message and add further back-off logic.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Thread Starter aetherscythe

    (@aetherscythe)

    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.

    Thread Starter aetherscythe

    (@aetherscythe)

    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. 😉

    Plugin Author brandtoss

    (@brandtoss)

    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.

    Plugin Author brandtoss

    (@brandtoss)

    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.

    Thread Starter aetherscythe

    (@aetherscythe)

    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 1 year, 11 months ago by aetherscythe.
    Thread Starter aetherscythe

    (@aetherscythe)

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

    Thread Starter aetherscythe

    (@aetherscythe)

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

    Thread Starter aetherscythe

    (@aetherscythe)

    @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.

    Plugin Author brandtoss

    (@brandtoss)

    Described edge case fixed in v1.6.16

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Throttle not enforced; error in logs, “A non-numeric value encountered”’ is closed to new replies.