DatabaseQueue is trying to increase attempts to 256, but the migration for job sets this to a max of 255 (php artisan queue:table). It shouldn't even be attempting the job because it's at the default max number of retries (255)
Numeric value out of range: 1264 Out of range value for column 'attempts' at row 1
I have the failed_jobs table create too, so it's odd that the job isn't being moved into the failed jobs table...
development.ERROR: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'attempts' at row 1 (SQL: update `jobs` set `reserved_at` = 1511521050, `attempts` = 256 where `id` = 525) {"exception":"[object] (Illuminate\\Database\\QueryException(code: 22003): SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'attempts' at row 1 (SQL: update `jobs` set `reserved_at` = 1511521050, `attempts` = 256 where `id` = 525) at /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Database/Connection.php:664, Doctrine\\DBAL\\Driver\\PDOException(code: 22003): SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'attempts' at row 1 at /Users/david/Projects/sentry-defence/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:107, PDOException(code: 22003): SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'attempts' at row 1 at /Users/david/Projects/sentry-defence/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:105)
[stacktrace]
#0 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Database/Connection.php(624): Illuminate\\Database\\Connection->runQueryCallback('update `jobs` s...', Array, Object(Closure))
#1 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Database/Connection.php(490): Illuminate\\Database\\Connection->run('update `jobs` s...', Array, Object(Closure))
#2 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Database/Connection.php(423): Illuminate\\Database\\Connection->affectingStatement('update `jobs` s...', Array)
#3 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php(2149): Illuminate\\Database\\Connection->update('update `jobs` s...', Array)
#4 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Queue/DatabaseQueue.php(279): Illuminate\\Database\\Query\\Builder->update(Array)
#5 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Queue/DatabaseQueue.php(260): Illuminate\\Queue\\DatabaseQueue->markJobAsReserved(Object(Illuminate\\Queue\\Jobs\\DatabaseJobRecord))
#6 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Queue/DatabaseQueue.php(195): Illuminate\\Queue\\DatabaseQueue->marshalJob('default', Object(Illuminate\\Queue\\Jobs\\DatabaseJobRecord))
#7 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(244): Illuminate\\Queue\\DatabaseQueue->pop('default')
#8 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(105): Illuminate\\Queue\\Worker->getNextJob(Object(Illuminate\\Queue\\DatabaseQueue), 'default')
#9 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(101): Illuminate\\Queue\\Worker->daemon('database', 'default', Object(Illuminate\\Queue\\WorkerOptions))
#10 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(85): Illuminate\\Queue\\Console\\WorkCommand->runWorker('database', 'default')
#11 [internal function]: Illuminate\\Queue\\Console\\WorkCommand->handle()
#12 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(29): call_user_func_array(Array, Array)
#13 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(87): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#14 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(31): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#15 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Container/Container.php(549): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#16 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Console/Command.php(180): Illuminate\\Container\\Container->call(Array)
#17 /Users/david/Projects/sentry-defence/vendor/symfony/console/Command/Command.php(240): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#18 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Console/Command.php(167): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#19 /Users/david/Projects/sentry-defence/vendor/symfony/console/Application.php(858): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#20 /Users/david/Projects/sentry-defence/vendor/symfony/console/Application.php(216): Symfony\\Component\\Console\\Application->doRunCommand(Object(Illuminate\\Queue\\Console\\WorkCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#21 /Users/david/Projects/sentry-defence/vendor/symfony/console/Application.php(122): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#22 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Console/Application.php(88): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#23 /Users/david/Projects/sentry-defence/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(121): Illuminate\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#24 /Users/david/Projects/sentry-defence/artisan(37): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#25 {main}
"}
The work around for this is to ensure that your Job defines tries, and they're <= 255
public $tries = 10;
Yes you need to define a maximum number of tries in all cases, that's the best practice, you shouldn't reach the maximum.
You what?...
Then the abstract Job class should be setting public $tries = 255, to prevent this error occurring!!
This is a framework, the jobs table is created by the framework (via artisan queue:table) and all the functionally is out of the box.
It's being provided broken out of the box, saying it's "best practice" to always set $tries is nonsense, it's "best practice" to make sure the framework doesn't break when used out of the box.
There is a hard limit on the jobs table of 255 retries, so the abstract job class should set the same hard limit.
Putting that responsibility onto the developer is insane. It shouldn't be possible to create broken jobs in this way.
Further to this. This little "caveat" isn't documented. nowhere does it state you MUST set tries when creating jobs - only that you CAN. which makes your statement patently false.
Just document the limitation that would be enough.
@SlyDave You don't have to set tries per job, just set it on your worker, having infinite number of retries doesn't make any sense.
@Kyslik it's a silly thing to document "We set the limit in the database, but didn't in the code, so erm, make sure you always set retries on your worker or in your job or it will crash, soz."
@themsaid You're right, you don't _have_ to, but if you don't it crashes - that's crap framework implementation, don't you think?
It's also perfectly fine and acceptable to want to retry infinitely, but seeing as the jobs table defines retires as 255 max, the framework has decided it won't support infinite retries (which is fine) but it then doesn't enforce this limit, and crashes when you try to go over it.
Further to this, saying you _should_ define it on your worker, (and it crashes when you don't) implies it should have a default configured that prevents it from crashing, or that you shouldn't be able to run the worker without proving a retry count.
This is a disconnect between design and implementation. What makes sense, and what doesn't isn't the issue, a decision about how it should work (max 255 tries) has already been made, the implementation doesn't enforce this.
I have $tries = 10; set on the job, still receiving this issue.
Most helpful comment
You what?...
Then the abstract Job class should be setting public $tries = 255, to prevent this error occurring!!
This is a framework, the jobs table is created by the framework (via artisan queue:table) and all the functionally is out of the box.
It's being provided broken out of the box, saying it's "best practice" to always set $tries is nonsense, it's "best practice" to make sure the framework doesn't break when used out of the box.
There is a hard limit on the jobs table of 255 retries, so the abstract job class should set the same hard limit.
Putting that responsibility onto the developer is insane. It shouldn't be possible to create broken jobs in this way.
Further to this. This little "caveat" isn't documented. nowhere does it state you MUST set tries when creating jobs - only that you CAN. which makes your statement patently false.