framework: ErrorException: Warning: Error while sending STMT_PREPARE packet

As replied by a dev from Sentry in the sentry-laravel issue

Interesting. We would have to dig where the warning is emitted from since it might not be silenced and thus will be caught by Sentry which is correct.

Since 2.x of the base SDK (and 1.x of Laravel) “errors” (like warnings and notices) are captured much better which might be the reason of the uptick of the errors. We also now capture every “error” by default which you can change using the error_types option.

To reiterate what is said in the other issues, this is a warning and Laravel recovers from this gracefully so it’s mere informational that this warning is emitted, it does not crash your apps or jobs these warnings were always emitted but not always captured.

Getting the same issue. Never had this issue on Laravel 5.6 but after updating to 5.7 this now happens daily. It looks like jobs are not actually failing since I have no items in the failed_jobs table, yet Sentry reports 80 issues. We are working with MySQL so not mariadb related

All these issues seem to be related:

• PDO::prepare(): MySQL server has gone away
• E_WARNING: Error while sending STMT_PREPARE packet. PID=10

I continue obtaining the error even though apply the code from last comment

I ended up adding this method to Exceptions/Handler.php:

public function shouldReport(Exception $e)
    {
        // check if sentry is trying to falsely report 'Warning: Error while sending STMT_PREPARE packet. PID=XX'
        if (strpos($e->getMessage(), 'STMT_PREPARE packet') !== 'false') {
            return parent::shouldReport($e);
        }
    }```

I ended up adding this method to Exceptions/Handler.php:

public function shouldReport(Exception $e)
    {
        // check if sentry is trying to falsely report 'Warning: Error while sending STMT_PREPARE packet. PID=XX'
        if (strpos($e->getMessage(), 'STMT_PREPARE packet') !== 'false') {
            return parent::shouldReport($e);
        }
    }```

public function shouldReport(Exception $e)
{
        // check if sentry is trying to falsely report 'Warning: Error while sending STMT_PREPARE packet. PID=XX'
        if (strpos($e->getMessage(), 'STMT_PREPARE packet') === false) {
            return parent::shouldReport($e);
        }
}

I’m with @Christophvh on the question about Sentry.

The error itself is pretty normal for long running jobs, but it supposed to be caught by the framework and transformed to a QueryException (which in turn triggers the re-connection to the database), so it should never reach Sentry in its native form. But it does. (Maybe even before the framework catches and handles it? That would explain why there’s no failed jobs)

So the question remains: do we all use Sentry?

I do: "sentry/sentry-laravel": "^1.0.0", And also updated it to 1.0 the same time we did the 5.8 update.

Many users are reporting similar experiences on Laracasts

https://laracasts.com/discuss/channels/laravel/error-while-sending-stmt-prepare-packet-on-queued-jobs

@mrahmadt What happens if the error message does NOT contain ‘STMT_PREPARE packet’?

In your case it’s undefined / not explicit, so I rewrote your code as follows:

    public function shouldReport(Exception $e)
    {
        // check if sentry is trying to falsely report 'Warning: Error while sending STMT_PREPARE packet. PID=XX'
        // see https://github.com/laravel/framework/issues/28920
        if (strpos($e->getMessage(), 'STMT_PREPARE packet') !== false) {
            return false;
        }

        return parent::shouldReport($e);
    }

I’m going to close this as this seems to be Sentry specific and there really isn’t an issue except from the warning. Thanks to everyone who helped investigate this 👍

I have had it with 1 and also with 40, so i don’t think it has anything to do with the amount of workers

@markdza @Mult1Hunter you can find the issue here https://github.com/getsentry/sentry-laravel/issues/254#issuecomment-512715265 seems like nothing to do with laravel itself.

So the question remains: do we all use Sentry?

I do use Sentry. And I don’t recall seeing the issue reported in HoneyBadger, which I also use.

Just got hit with one today 😦 @koenhoeijmakers is right. The error has nothing to do with the amount of workers. Sentry says it failed making a request to grab user_settings from MYSQL during a job call.

ErrorException: Warning: Error while sending STMT_PREPARE packet. PID=27771 ErrorException: Warning: PDO::prepare(): MySQL server has gone away.

What we do know:

• Database choice (mysql, mariaDB, etc.) does not matter so its not the database type.
• The number of workers does not solve the problem either.
• Horizon and Telescope are not the issue. (some people are using them others are not)
• The error does not create a record in the failed_job table.

I too am facing this issue. I am not using horizon or telescope. I do not have any jobs that are shown as failed in my DB but I do get the notifications a few times a day. It fails randomly on any job in the program. I have very little traffic on the server. I have been trying to figure it out for the past few days now.

I only receive the “Error while sending STMT_PREPARE packet. PID=*” I have not received the “MYSQL server has gone away.”

Laravel 5.8.28 MYSQL version: 5.7.26

The server is deployed using forge. My worker settings: connection = redis queue = default timeout = 0 processes = 1 tries = 3

I am going to bump up the processes number and see if that helps and then I’ll report back

I do not use telescope so i don’t think the problem lies there, no transactions too

Im not using horizon nor telescope and face this issue

I’m passing Eloquent model to the queued job constructor, maybe this is the issue

Any one doing the same thing ?

On Fri, Jul 12, 2019 at 17:38 jlmmns notifications@github.com wrote:

@driesvints https://github.com/driesvints No transactions.

It seems it has to do with Horizon/Telescope. Although Telescope is fully disabled.

Below you can find some of our Sentry logs:

[image: Screen Shot 2019-07-12 at 9 35 07 AM] https://user-images.githubusercontent.com/3619890/61136110-9d1de380-a488-11e9-8be5-bbb4e502d071.png

[image: Screen Shot 2019-07-12 at 9 34 16 AM] https://user-images.githubusercontent.com/3619890/61136129-a5761e80-a488-11e9-8c71-00d86a2c7beb.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/laravel/framework/issues/28920?email_source=notifications&email_token=AAHJ3YNWIWKDS74BKT4B64DP7CJODA5CNFSM4H2XQDTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZ6CXA#issuecomment-510910812, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHJ3YMC4TABMGIQY6PKDHDP7CJODANCNFSM4H2XQDTA .

– echo “Hello World 😃”

@driesvints 3 separate listeners are failing in our application and none of them have database-transactions. It might indeed be a horizon update, we started to notice it after a composer update. We don’t use telescope so horizon seems most likely.

Same issue from April 28: https://github.com/laravel/horizon/issues/583

Also in stackoverflow

And most of the cases its laravel not lumen

On Sun, Jun 30, 2019 at 13:25 decowboy notifications@github.com wrote:

Many users are reporting similar experiences on Laracasts

https://laracasts.com/discuss/channels/laravel/error-while-sending-stmt-prepare-packet-on-queued-jobs

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/laravel/framework/issues/28920?email_source=notifications&email_token=AAHJ3YIHWUDFAD2EZM2PX7DP5CC3NA5CNFSM4H2XQDTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4JMVI#issuecomment-507024981, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHJ3YLOMPMBI2FGAWJDWS3P5CC3NANCNFSM4H2XQDTA .

– echo “Hello World 😃”