framework: [5.1] Jobs fail to run when a dependent model is deleted

Thanks @valorin for the 5.1 example. This works for me, while running Laravel 5.2:

namespace App\Traits;

use Illuminate\Contracts\Database\ModelIdentifier;

/**
 * Class SerialisesDeletedModels
 * @see https://github.com/laravel/framework/issues/9347#issuecomment-165647596
 */
trait SerialisesDeletedModels
{
    /**
     * @param $value
     * @return mixed
     */
    protected function getRestoredPropertyValue($value)
    {
        if (!$value instanceof ModelIdentifier) {
            return $value;
        }

        if (is_array($value->id)) {
            return $this->restoreCollection($value);
        }

        $instance = new $value->class;
        $query = $instance->newQuery()->useWritePdo();

        if (property_exists($instance, 'forceDeleting')) {
            return $query->withTrashed()->find($value->id);
        }

        return $query->findOrFail($value->id);
    }
}

I made a new trait and overrode the method:

use SerializesModels, SerialisesDeletedModels {
    SerialisesDeletedModels::getRestoredPropertyValue insteadof SerializesModels;
}

use Illuminate\Contracts\Database\ModelIdentifier;

trait SerialisesDeletedModels
{
    protected function getRestoredPropertyValue($value)
    {
        if ($value instanceof ModelIdentifier) {
            $model = new $value->class;

            if (method_exists($model, 'withTrashed')) {
                return $model->withTrashed()->findOrFail($value->id);
            }

            return $model->findOrFail($value->id);
        } else {
            return $value;
        }
    }
}

@GrahamCampbell @EvanDarwin This is actually an issue with you’re dealing with Soft Deletes. If you try to pass a soft-deleted model into a queued job, it will fail because findOrFail() won’t find it - but the model is a perfectly valid model and is still usable.

For example, we have a common class that handles marking models as deleted on the form submission. It then fires a ModelWasDeleted event. I am trying to set up a listener for that event that will queue a job with the deleted event to clean up extra data in the background - but it’s failing because I am passing the deleted model into it.

A simple work-around is to pass in the ID, rather than the model itself. However, this breaks our usual pattern and the change in behaviour when using SerializesModels isn’t really expected.

Or remove SerializeModels for deleted resources?

Good one. I guess I could have used withTrashed()->findOrFail(), but in this case I only used soft-deleting models so a record would always exist.

When you use soft-delete models and a job gets queued with a non-existing (i.e. no database record) soft-deleted model in it then there is a serious problem: that is a situation that theoretically should not exist 😄