Imagine the situation. I have a delayed job to do something with the post model, but before the job process I delete the post.
Today I use the trait indicated in this discuss.
But now I'm thinking, this kind of exception should be treated in another place, for example in the failed method.
What do you think about this @taylorotwell and @GrahamCampbell?
namespace App\Jobs;
use App\Post;
use Illuminate\Bus\Queueable;
use Illuminate\Support\Facades\Log;
use Illuminate\Queue\{InteractsWithQueue, SerializesModels};
use Illuminate\Contracts\Queue\ShouldQueue;
class Example implements ShouldQueue
{
use InteractsWithQueue, Queueable, SerializesModels;
protected $post;
public function __construct(Post $post)
{
$this->post = $post;
}
public function handle()
{
Log::debug($post->title);
}
// The idea sketch
public function foo(Exception $e)
{
if ($e instanceof ModelNotFoundException) {
// do something
}
}
}
There is another issue with a similar problem #9347, but with soft deletes.
Yeh, this is unfortunate, but is the expected behaviour.
If in your queue jobs you don't actually need to interact with the model, and just needed to read some properties, I'd suggest just passing through those properties instead of a model.
That's what I do for sending all my mail for example. Makes it possible to send account deletion emails!
Thanks @GrahamCampbell.
Most helpful comment
That's what I do for sending all my mail for example. Makes it possible to send account deletion emails!