Job has been attempted too many times or run too long
up vote
8
down vote
favorite
I have a job that works flawless locally, but in production I run into issues where it doesn't work. I've encompassed the entire handle() with a try/catch and am not seeing anything logged to Bugsnag, despite many other exceptions elsewhere from being deployed.
public function handle()
try
// do stuff
catch (Exception $e)
Bugsnag::notifyException($e);
throw $e;
According to Laravel Horizon this queue job runs for 0.0026001930236816406 seconds and I never see it work and never see any other errors in the failed_jobs table as it relates to this job.
config/queue.php
'redis' => [
'driver' => 'redis',
'connection' => 'default',
'queue' => 'default',
'retry_after' => (60 * 10), // 10 minutes
'block_for' => null,
],
config/horizon.php
'environments' => [
'production' => [
'supervisor' => [
'connection' => 'redis',
'queue' => [
'default',
],
'balance' => 'auto',
'processes' => 10,
'tries' => 3,
// 10 seconds under the queue's retry_after to avoid overlap
'timeout' => (60 * 10) - 10, // Just under 10 mins
],
If something is causing this job to retry over and over, how can I find out how? I'm at a loss.
Investigation thus far
- My expectation is I should be able to run the query:
SELECT DISTINCT exception, COUNT(id) as errors
FROM failed_jobs
WHERE payload LIKE '%[TAG-JOB-HAS]%'
GROUP BY exception;
To see more than this error message:
Job has been attempted too many times or run too long
but that's all I see.
Laravel Horizon's dashboard shows the job in question is running for < 1 second, so I know it's not actually timing out.
laravel queue horizon
|
show 2 more comments
up vote
8
down vote
favorite
I have a job that works flawless locally, but in production I run into issues where it doesn't work. I've encompassed the entire handle() with a try/catch and am not seeing anything logged to Bugsnag, despite many other exceptions elsewhere from being deployed.
public function handle()
try
// do stuff
catch (Exception $e)
Bugsnag::notifyException($e);
throw $e;
According to Laravel Horizon this queue job runs for 0.0026001930236816406 seconds and I never see it work and never see any other errors in the failed_jobs table as it relates to this job.
config/queue.php
'redis' => [
'driver' => 'redis',
'connection' => 'default',
'queue' => 'default',
'retry_after' => (60 * 10), // 10 minutes
'block_for' => null,
],
config/horizon.php
'environments' => [
'production' => [
'supervisor' => [
'connection' => 'redis',
'queue' => [
'default',
],
'balance' => 'auto',
'processes' => 10,
'tries' => 3,
// 10 seconds under the queue's retry_after to avoid overlap
'timeout' => (60 * 10) - 10, // Just under 10 mins
],
If something is causing this job to retry over and over, how can I find out how? I'm at a loss.
Investigation thus far
- My expectation is I should be able to run the query:
SELECT DISTINCT exception, COUNT(id) as errors
FROM failed_jobs
WHERE payload LIKE '%[TAG-JOB-HAS]%'
GROUP BY exception;
To see more than this error message:
Job has been attempted too many times or run too long
but that's all I see.
Laravel Horizon's dashboard shows the job in question is running for < 1 second, so I know it's not actually timing out.
laravel queue horizon
1
Have you tried logging debug statements to prove that the job has actually been run? Can you include more information about what the job actually does, and maybe some code? It could be failing in a way that doesn't generate exceptions
– Travis Britz
Nov 4 at 1:52
1
"...but in production I run into issues where it doesn't work" - what doesnt work exactly? Do you see an error in the logs?
– Laurence
Nov 4 at 8:57
Just a thought, is it theBugsnag::notifyException($e)line that is causing an exception, causing Laravel to requeue your job to retry?
– Jamesking56
Nov 5 at 17:27
What is "// do stuff"? Does it do anything weird like call exit() or die()?
– Travis Britz
Nov 6 at 11:28
Did you restart the queue after adding the try catch to the handle function?
– Elie
Nov 6 at 13:28
|
show 2 more comments
up vote
8
down vote
favorite
up vote
8
down vote
favorite
I have a job that works flawless locally, but in production I run into issues where it doesn't work. I've encompassed the entire handle() with a try/catch and am not seeing anything logged to Bugsnag, despite many other exceptions elsewhere from being deployed.
public function handle()
try
// do stuff
catch (Exception $e)
Bugsnag::notifyException($e);
throw $e;
According to Laravel Horizon this queue job runs for 0.0026001930236816406 seconds and I never see it work and never see any other errors in the failed_jobs table as it relates to this job.
config/queue.php
'redis' => [
'driver' => 'redis',
'connection' => 'default',
'queue' => 'default',
'retry_after' => (60 * 10), // 10 minutes
'block_for' => null,
],
config/horizon.php
'environments' => [
'production' => [
'supervisor' => [
'connection' => 'redis',
'queue' => [
'default',
],
'balance' => 'auto',
'processes' => 10,
'tries' => 3,
// 10 seconds under the queue's retry_after to avoid overlap
'timeout' => (60 * 10) - 10, // Just under 10 mins
],
If something is causing this job to retry over and over, how can I find out how? I'm at a loss.
Investigation thus far
- My expectation is I should be able to run the query:
SELECT DISTINCT exception, COUNT(id) as errors
FROM failed_jobs
WHERE payload LIKE '%[TAG-JOB-HAS]%'
GROUP BY exception;
To see more than this error message:
Job has been attempted too many times or run too long
but that's all I see.
Laravel Horizon's dashboard shows the job in question is running for < 1 second, so I know it's not actually timing out.
laravel queue horizon
I have a job that works flawless locally, but in production I run into issues where it doesn't work. I've encompassed the entire handle() with a try/catch and am not seeing anything logged to Bugsnag, despite many other exceptions elsewhere from being deployed.
public function handle()
try
// do stuff
catch (Exception $e)
Bugsnag::notifyException($e);
throw $e;
According to Laravel Horizon this queue job runs for 0.0026001930236816406 seconds and I never see it work and never see any other errors in the failed_jobs table as it relates to this job.
config/queue.php
'redis' => [
'driver' => 'redis',
'connection' => 'default',
'queue' => 'default',
'retry_after' => (60 * 10), // 10 minutes
'block_for' => null,
],
config/horizon.php
'environments' => [
'production' => [
'supervisor' => [
'connection' => 'redis',
'queue' => [
'default',
],
'balance' => 'auto',
'processes' => 10,
'tries' => 3,
// 10 seconds under the queue's retry_after to avoid overlap
'timeout' => (60 * 10) - 10, // Just under 10 mins
],
If something is causing this job to retry over and over, how can I find out how? I'm at a loss.
Investigation thus far
- My expectation is I should be able to run the query:
SELECT DISTINCT exception, COUNT(id) as errors
FROM failed_jobs
WHERE payload LIKE '%[TAG-JOB-HAS]%'
GROUP BY exception;
To see more than this error message:
Job has been attempted too many times or run too long
but that's all I see.
Laravel Horizon's dashboard shows the job in question is running for < 1 second, so I know it's not actually timing out.
laravel queue horizon
laravel queue horizon
edited Nov 9 at 14:37
HCK
2,8911829
2,8911829
asked Oct 31 at 2:11
Webnet
29.9k84245412
29.9k84245412
1
Have you tried logging debug statements to prove that the job has actually been run? Can you include more information about what the job actually does, and maybe some code? It could be failing in a way that doesn't generate exceptions
– Travis Britz
Nov 4 at 1:52
1
"...but in production I run into issues where it doesn't work" - what doesnt work exactly? Do you see an error in the logs?
– Laurence
Nov 4 at 8:57
Just a thought, is it theBugsnag::notifyException($e)line that is causing an exception, causing Laravel to requeue your job to retry?
– Jamesking56
Nov 5 at 17:27
What is "// do stuff"? Does it do anything weird like call exit() or die()?
– Travis Britz
Nov 6 at 11:28
Did you restart the queue after adding the try catch to the handle function?
– Elie
Nov 6 at 13:28
|
show 2 more comments
1
Have you tried logging debug statements to prove that the job has actually been run? Can you include more information about what the job actually does, and maybe some code? It could be failing in a way that doesn't generate exceptions
– Travis Britz
Nov 4 at 1:52
1
"...but in production I run into issues where it doesn't work" - what doesnt work exactly? Do you see an error in the logs?
– Laurence
Nov 4 at 8:57
Just a thought, is it theBugsnag::notifyException($e)line that is causing an exception, causing Laravel to requeue your job to retry?
– Jamesking56
Nov 5 at 17:27
What is "// do stuff"? Does it do anything weird like call exit() or die()?
– Travis Britz
Nov 6 at 11:28
Did you restart the queue after adding the try catch to the handle function?
– Elie
Nov 6 at 13:28
1
1
Have you tried logging debug statements to prove that the job has actually been run? Can you include more information about what the job actually does, and maybe some code? It could be failing in a way that doesn't generate exceptions
– Travis Britz
Nov 4 at 1:52
Have you tried logging debug statements to prove that the job has actually been run? Can you include more information about what the job actually does, and maybe some code? It could be failing in a way that doesn't generate exceptions
– Travis Britz
Nov 4 at 1:52
1
1
"...but in production I run into issues where it doesn't work" - what doesnt work exactly? Do you see an error in the logs?
– Laurence
Nov 4 at 8:57
"...but in production I run into issues where it doesn't work" - what doesnt work exactly? Do you see an error in the logs?
– Laurence
Nov 4 at 8:57
Just a thought, is it the
Bugsnag::notifyException($e) line that is causing an exception, causing Laravel to requeue your job to retry?– Jamesking56
Nov 5 at 17:27
Just a thought, is it the
Bugsnag::notifyException($e) line that is causing an exception, causing Laravel to requeue your job to retry?– Jamesking56
Nov 5 at 17:27
What is "
// do stuff"? Does it do anything weird like call exit() or die()?– Travis Britz
Nov 6 at 11:28
What is "
// do stuff"? Does it do anything weird like call exit() or die()?– Travis Britz
Nov 6 at 11:28
Did you restart the queue after adding the try catch to the handle function?
– Elie
Nov 6 at 13:28
Did you restart the queue after adding the try catch to the handle function?
– Elie
Nov 6 at 13:28
|
show 2 more comments
2 Answers
2
active
oldest
votes
up vote
4
down vote
Try to catch the exception in failed method given by laravel
/**
* The job failed to process.
*
* @param Exception $exception
* @return void
*/
public function failed(Exception $exception)
// Send user notification of failure, etc...
and check whether your default queue driver in local is sync then its expected behaviour
add a comment |
up vote
3
down vote
According to documentation, you can handle job failing in two common ways:
- using failed job events
- using
failed()method.
In first case you can handle all jobs using Queue::failing method. You'll receive IlluminateQueueEventsJobFailed event as a parameter, and it contains exception.
In other case you can use failed() method, it should be placed near your handle() method. You can receive Exception $exception as a parameter too.
Example:
public function failed(Throwable $exception)
// Log failure
Hope this helps.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
Try to catch the exception in failed method given by laravel
/**
* The job failed to process.
*
* @param Exception $exception
* @return void
*/
public function failed(Exception $exception)
// Send user notification of failure, etc...
and check whether your default queue driver in local is sync then its expected behaviour
add a comment |
up vote
4
down vote
Try to catch the exception in failed method given by laravel
/**
* The job failed to process.
*
* @param Exception $exception
* @return void
*/
public function failed(Exception $exception)
// Send user notification of failure, etc...
and check whether your default queue driver in local is sync then its expected behaviour
add a comment |
up vote
4
down vote
up vote
4
down vote
Try to catch the exception in failed method given by laravel
/**
* The job failed to process.
*
* @param Exception $exception
* @return void
*/
public function failed(Exception $exception)
// Send user notification of failure, etc...
and check whether your default queue driver in local is sync then its expected behaviour
Try to catch the exception in failed method given by laravel
/**
* The job failed to process.
*
* @param Exception $exception
* @return void
*/
public function failed(Exception $exception)
// Send user notification of failure, etc...
and check whether your default queue driver in local is sync then its expected behaviour
answered Nov 6 at 13:32
Anil Kumar
1564
1564
add a comment |
add a comment |
up vote
3
down vote
According to documentation, you can handle job failing in two common ways:
- using failed job events
- using
failed()method.
In first case you can handle all jobs using Queue::failing method. You'll receive IlluminateQueueEventsJobFailed event as a parameter, and it contains exception.
In other case you can use failed() method, it should be placed near your handle() method. You can receive Exception $exception as a parameter too.
Example:
public function failed(Throwable $exception)
// Log failure
Hope this helps.
add a comment |
up vote
3
down vote
According to documentation, you can handle job failing in two common ways:
- using failed job events
- using
failed()method.
In first case you can handle all jobs using Queue::failing method. You'll receive IlluminateQueueEventsJobFailed event as a parameter, and it contains exception.
In other case you can use failed() method, it should be placed near your handle() method. You can receive Exception $exception as a parameter too.
Example:
public function failed(Throwable $exception)
// Log failure
Hope this helps.
add a comment |
up vote
3
down vote
up vote
3
down vote
According to documentation, you can handle job failing in two common ways:
- using failed job events
- using
failed()method.
In first case you can handle all jobs using Queue::failing method. You'll receive IlluminateQueueEventsJobFailed event as a parameter, and it contains exception.
In other case you can use failed() method, it should be placed near your handle() method. You can receive Exception $exception as a parameter too.
Example:
public function failed(Throwable $exception)
// Log failure
Hope this helps.
According to documentation, you can handle job failing in two common ways:
- using failed job events
- using
failed()method.
In first case you can handle all jobs using Queue::failing method. You'll receive IlluminateQueueEventsJobFailed event as a parameter, and it contains exception.
In other case you can use failed() method, it should be placed near your handle() method. You can receive Exception $exception as a parameter too.
Example:
public function failed(Throwable $exception)
// Log failure
Hope this helps.
answered Nov 9 at 22:39
a_sarana
232112
232112
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53075318%2fjob-has-been-attempted-too-many-times-or-run-too-long%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Have you tried logging debug statements to prove that the job has actually been run? Can you include more information about what the job actually does, and maybe some code? It could be failing in a way that doesn't generate exceptions
– Travis Britz
Nov 4 at 1:52
1
"...but in production I run into issues where it doesn't work" - what doesnt work exactly? Do you see an error in the logs?
– Laurence
Nov 4 at 8:57
Just a thought, is it the
Bugsnag::notifyException($e)line that is causing an exception, causing Laravel to requeue your job to retry?– Jamesking56
Nov 5 at 17:27
What is "
// do stuff"? Does it do anything weird like call exit() or die()?– Travis Britz
Nov 6 at 11:28
Did you restart the queue after adding the try catch to the handle function?
– Elie
Nov 6 at 13:28