1

I'm working on a project using laravel 4.2, and i'm sending jobs to a beanstalk queue. When the worker picks up the job to execute, I'm trying to capture the id of the job, and associate it back to the failed_jobs table in the event the job fails.

The problem is that the id returned from the Pheanstalk_Job->getId() method, never matches the id of the entry in the failed_jobs table.

I may be presumptuous in thinking that the two are correlated. If not, then hopefully someone can help with how I can achieve capturing the id of the failed_jobs record as it pertains to the job.

Brett
  • 149
  • 13
  • You would probably be better off inserting your own meta-information in the jobs that you create with a unique ID and checking against that. Any IDs that the beanstalkd returns are likely to be quite transient. – Alister Bulman Apr 01 '16 at 09:07

1 Answers1

0

Ultimately, my solution to create a correlation between the exception that caused the job to fail, and the entry created in the failed_jobs table involved the following steps:

  1. Created a migration that created an exception table that included the exception fields i.e. exception message, code, file, line, and also a field for the beanstalkd job id.
  2. Created a migration that is exactly modeled after the failed_jobs schema provided by laravel with the addition of another field, the beanstalkd job id as well.
  3. Created my own QueueServiceProvider and bound the 'queue.failer' and 'queue.worker' services with my own implementations. My 'failer' implementation extends the Illuminate\Queue\Failed\DatabaseFailedJobProvider and simply adds a method for doing an insert that includes the beanstalkd job id. My 'worker' implementation extends the Illuminate\Queue\Worker and overrides the logFailedJob method to call my own failed job insert method.
  4. In app/config/queue.php I included, 'failed' => ['database' => 'mysql', 'table' => 'exception_failed_jobs'] to tell laravel to use my own failed jobs table called 'exception_failed_jobs'.
  5. In my job handler code, the fire method wraps my business logic in a try/catch, and any exceptions raised, will result in the exception being stored in my exception table, including the beanstalkd job id.

Now all the exceptions raised have a correlation to the failed job record via the job id. The business can now determine the exception that caused the job to fail, and decide whether to correct the underlying issue and retry the failed job, or simply delete it off the queue. I've tested this solution and it works exactly as I need it to. Hopefully this helps anyone else out with the same requirement.

Can't wait to migrate this project off 4.2 and on to the latest version. I understand that the latest laravel has this functionality already baked in :)

Brett
  • 149
  • 13