Blog

You dispatch a queue job right after saving a model. The job picks it up in milliseconds. And then — ModelNotFoundException.

The model definitely exists. You just created it. You can query it manually. But the queue worker says otherwise.

The Culprit: Read Replicas

If your database uses read replicas (and most production setups do), there’s a lag between the primary and the replicas. Usually milliseconds, sometimes longer under load.

Laravel’s SerializesModels trait only stores the model’s ID when the job is serialized. When the worker deserializes it, it runs a fresh query — against the read replica. If the replica hasn’t caught up yet, the model doesn’t exist from the worker’s perspective.

The cruel part: this happens before your handle() method runs. Your retry logic never fires because the job fails during deserialization.

The Fix: afterCommit()

Laravel has a built-in solution. Add afterCommit to your job:

class GenerateInvoice implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public $afterCommit = true;

    public function handle(): void
    {
        // This now runs after the transaction commits
        // and the replica has had time to sync
    }
}

Or dispatch with the method:

GenerateInvoice::dispatch($invoice)->afterCommit();

Other Options

If afterCommit isn’t enough (replicas can still lag after commit), you have two more tools:

// Option 1: Add a small delay
GenerateInvoice::dispatch($invoice)->delay(now()->addSeconds(5));

// Option 2: Skip missing models instead of failing
public $deleteWhenMissingModels = true;

Option 2 is a silent skip — the job just disappears. Use it only when the job is truly optional (like sending a notification for a model that might get deleted).

The Lesson

If you’re dispatching queue jobs immediately after writes and seeing phantom ModelNotFoundException errors, check your database topology. Read replicas + SerializesModels + fast workers = a race condition that only shows up under load. afterCommit() is the cleanest fix.

When defining translation strings in Laravel, always use named placeholders (like :count or :percent) instead of positional ones or manual string concatenation.

// Bad
__('You have ' . $count . ' notifications');

// Good
__('You have :count notifications', ['count' => $count]);

Different languages have varying word orders; named placeholders allow translators to move variables within the sentence without breaking the logic or requiring code changes for each locale.

When duplicating complex UI validation or calculation logic on the backend, treat the frontend component as the source of truth. Copy the logic line-by-line into your PHP services, and include comments with the original file and line numbers.

// Replicating logic from ProductForm.vue:142
if ($data['price'] > 0) {
    // ...
}

This makes future parity checks easier and ensures your backend handles edge cases exactly as the user experience defines them. It also serves as great documentation for why certain backend checks exist.

I’ve seen this pattern in multiple Laravel codebases — a translation helper that manually fetches the locale before passing it to the translation function:

// Don't do this
$locale = App::getLocale();
$label = __('orders.status_label', [], $locale);

That third parameter is unnecessary. The __() helper already calls App::getLocale() internally when no locale is provided.

How __() Actually Works

Under the hood, __() delegates to the Translator’s get() method:

// Illuminate\Translation\Translator::get()
public function get($key, array $replace = [], $locale = null, $fallback = true)
{
    $locale = $locale ?: $this->locale;
    // ...
}

When $locale is null (the default), it uses $this->locale — which is the application locale set by App::setLocale(). It’s the same value App::getLocale() returns.

So the clean version is just:

// Do this instead
$label = __('orders.status_label');

When You DO Need the Locale Parameter

The third parameter exists for a reason — when you need a translation in a specific locale that differs from the current one:

// Sending an email in the user's preferred language
$subject = __('emails.welcome_subject', [], $user->preferred_locale);

// Generating a PDF in a specific language regardless of current request
$label = __('invoice.total', [], 'ja');

These are legitimate uses. The anti-pattern is fetching the current locale just to pass it right back.

The Compound Version

This gets worse when the manual locale fetch spreads across a method:

// This entire method is doing unnecessary work
public function getLabels()
{
    $locale = App::getLocale();
    
    return [
        'name'    => __('fields.name', [], $locale),
        'email'   => __('fields.email', [], $locale),
        'phone'   => __('fields.phone', [], $locale),
        'address' => __('fields.address', [], $locale),
    ];
}

Every single $locale parameter is redundant. This should be:

public function getLabels()
{
    return [
        'name'    => __('fields.name'),
        'email'   => __('fields.email'),
        'phone'   => __('fields.phone'),
        'address' => __('fields.address'),
    ];
}

Same output, less noise, fewer places to introduce bugs. The framework already handles locale resolution — let it do its job.

You run npm run hot and Laravel Mix starts a webpack dev server with Hot Module Replacement. Your browser auto-refreshes when you edit Vue components or CSS. Magic. But have you ever wondered how Laravel knows to serve assets from the dev server instead of the compiled files in public/?

The answer is a tiny file you’ve probably never noticed: public/hot.

What public/hot Does

When you run npm run hot, Laravel Mix creates a file at public/hot. It contains the dev server URL — typically http://localhost:8080.

Laravel’s mix() helper checks for this file on every request:

// Simplified version of what mix() does internally
if (file_exists(public_path('hot'))) {
    $devServerUrl = rtrim(file_get_contents(public_path('hot')));
    return $devServerUrl . $path;
}

// No hot file? Serve from mix-manifest.json as normal
return $manifest[$path];

So when public/hot exists, mix('js/app.js') returns http://localhost:8080/js/app.js instead of /js/app.js?id=abc123.

When This Bites You

The classic gotcha: you kill the dev server with Ctrl+C, but the public/hot file doesn’t get cleaned up. Now your app is trying to load assets from a server that doesn’t exist.

# Symptoms: blank page, console full of ERR_CONNECTION_REFUSED
# Fix:
rm public/hot

Add it to your troubleshooting checklist. If assets suddenly stop loading after you were running HMR, check if public/hot is still hanging around.

Why This Matters for Teams

The public/hot file should always be in your .gitignore. If someone accidentally commits it, everyone else’s app will try to load assets from localhost:8080 — which won’t be running on their machines.

# .gitignore
public/hot

Most Laravel projects already have this, but if you bootstrapped your project a long time ago or generated your .gitignore manually, double-check.

It’s a tiny file with a simple job, but understanding it saves you 20 minutes of confused debugging when HMR stops working or your assets vanish after killing the dev server.