DEV Community

Cover image for Why Passing Eloquent Models to Queued Jobs Can Be Problematic
André Luiz Lunelli
André Luiz Lunelli

Posted on

Why Passing Eloquent Models to Queued Jobs Can Be Problematic

TL;DR

Avoid dispatching jobs with full Eloquent models.

SendOrderConfirmation::dispatch($user);
Enter fullscreen mode Exit fullscreen mode

Instead, pass only what the job actually needs.

SendOrderConfirmation::dispatch($user->id);
Enter fullscreen mode Exit fullscreen mode

Passing models can:

  1. Increase queue payload size
  2. Break jobs after deployments
  3. Expose sensitive data in logs or failed jobs

Smaller payloads make your system more resilient, predictable, and safer.

Read the Full Thing

I still see this pattern frequently in PRs. And to be clear — I'm not trying to turn this into a big issue. It works.

But it can also introduce surprisingly large problems for such a small decision.

1. Your queue payload may grow unexpectedly
And most of the time, this isn't intentional. In larger systems, it's easy to forget that a model may already have relationships loaded. Sometimes those relationships were loaded earlier in the request lifecycle — possibly by code you didn't even write.

$user->load('products');
Enter fullscreen mode Exit fullscreen mode

If that user has 50 products loaded, those relationships may end up serialized as part of the job payload when the job is pushed to the queue — whether you're using Amazon SQS, Redis.

Now the queue message contains far more data than the job actually needs.

In many cases, the job only requires something simple like:

  • the user id
  • the order id

Nothing else.

2. Deployments can break queued jobs
Now imagine this sequence:

  1. A job is dispatched with a serialized model
  2. A new deployment happens
  3. The model structure changes
  4. The job retries and attempts to deserialize the old payload

Suddenly, the worker cannot reconstruct the object correctly.

This creates fragile jobs and reduces fault tolerance.
Jobs should remain as independent and version-resilient as possible.

3. Sensitive data may end up in queue logs
When a model is serialized, its attributes may appear inside the queue payload.

That means information could show up in:

  • failed job logs
  • queue dashboards (like Horizon)
  • debugging tools
  • dead-letter queues

In regulated environments like healthcare or finance, this can become a compliance risk.

Even if passwords are hashed, other fields may still contain personally identifiable information (PII).

Minimizing the data you send to queues helps protect your system.


A safer pattern

Dispatch jobs with only the identifiers they need:

SendOrderConfirmation::dispatch($user->id);
Enter fullscreen mode Exit fullscreen mode

Then resolve the model inside the job:

public function handle(): void
{
    $user = User::findOrFail($this->userId);
}
Enter fullscreen mode Exit fullscreen mode

This keeps your jobs:

  • lighter
  • safer
  • easier to retry
  • more resilient to change

Sometimes the best PR feedback is simply:

“Do we really need to pass the whole model here?”

Most of the time, the answer is no.

Top comments (0)