0

I'm having hard time seeing what causes this error, so I'll try to explain exactly what happens and what I have here.

Laravel 7 project on shared hosting, with one cron task:

* * * * * artisan schedule:run >> /dev/null 2>&1

No Supervisor etc, so for now in ../Console/Kernel.php's schedule function I have:

    $schedule->command('queue:restart')
        ->everyFiveMinutes();

    $schedule->command('queue:work --daemon')
        ->everyMinute()
        ->withoutOverlapping();

    $schedule->command('myapp:mycommand')->daily();

What happens is that every midnight mycommand runs perfectly fine and it does its job. However, every night approx one hour later, something triggers 1615 error two times:

SQLSTATE[HY000]: General error: 1615 Prepared statement needs to be re-prepared 
(SQL: select * from `jobs` where `queue` = default and ((`reserved_at` is null and 
`available_at` <= 1604019606) or (`reserved_at` <= 1604019516)) order by `id` asc 
limit 1 for update)

The error stack is quite long, from artisan(37) to ../Illuminate/Database/Connection.php(631), and I'm a bit confused on how to track down this issue. After that artisan reference, all files of this stack are from laravel vendor.

I don't seem to understand what or why is happening an hour after my scheduled command, or if it even has anything to do with it.

Any ideas how to debug this better? It doesn't seem to break anything or to affect anything, but it sure is annoying.

EDIT:

As suggested, there's couple possible "fixes":

  1. ATTR_EMULATE_PREPARES in Laravels database config, and
  2. raising table_definition_cache in database itself.

The first one leads to other issues and the latter doesn't really work in shared hosting as you'd have to request service provider to raise it more and more all the time.

I got TDC increased to 1024 and the first 24h my app was error free. However, now I once again get those same errors, even over 20 pieces per 24h. They all still comes from job queue, yet so far all my jobs has been executed successfully. But I'm really concerned about this as other people are having similar errors triggered by their own code, it would be really bad if for example some emails wouldn't leave the app becouse of this.

kaarto
  • 747
  • 1
  • 8
  • 18
  • Does this answer your question? [Laravel: General error: 1615 Prepared statement needs to be re-prepared](https://stackoverflow.com/questions/31957441/laravel-general-error-1615-prepared-statement-needs-to-be-re-prepared) – Svetoslav Oct 30 '20 at 08:19
  • @Svetoslav I'm sure that solution would actually get rid of this error, but I was hoping to find a real cause of this issue and solution that wouldn't introduce possible security vulnerabilities or affect my validation layers. :/ – kaarto Oct 30 '20 at 08:26
  • The issue sounds more as SQL problem (or missconfiguration).. For laravel 1 recommendation is to set PDO ATTR_EMULATE_PREPARES at the db config. Out of laravel there is recommendation to set higher table_definition_cache at your DB.. – Svetoslav Oct 30 '20 at 08:31
  • @Svetoslav thanks! For now I got rid of it by rising TDC, but sadly that is only a temporary solution, as I can't keep rising it forever. Seems like MariaDB have had critical ticket open about this (same?) issue over 2 years now.. I was sure this wasn't the same issue as others are having, since in other questions the issue is triggered by user code, whereas my errors comes only from Laravels queue code in vendor. Would you care to form an answer, or shall I vote close? – kaarto Nov 01 '20 at 06:45
  • Yet I still don't understand what Laravel is doing an hour after running the command successfully, and causing this to trigger twice.. I mean, it doesn't affect anything, but not knowing why is really annoying. – kaarto Nov 01 '20 at 07:01

0 Answers0