Author: Daryle De Silva

Ever tried to automate Laravel Tinker commands in a Docker container or CI pipeline? If you’ve used stdin piping with heredocs, you probably discovered it just… doesn’t work reliably.

I spent way too long debugging why docker exec php artisan tinker with piped PHP commands would run silently and produce zero output. Turns out, Tinker’s interactive mode doesn’t play nice with stdin automation.

The solution that actually works? The --execute flag.

// ❌ This doesn't work reliably:
docker exec my-app bash -c "php artisan tinker <<'EOF'
\$user = App\Models\User::first();
echo \$user->email;
EOF"

// ✅ This does:
docker exec my-app php artisan tinker --execute="
\$user = App\Models\User::first();
echo \$user->email;
"

// Or for multi-line commands in bash scripts:
docker exec my-app php artisan tinker --execute="$(cat <<'EOF'
$user = App\Models\User::first();
$user->email = '[email protected]';
$user->save();
echo 'Updated: ' . $user->email;
EOF
)"

The --execute flag runs Tinker in non-interactive mode. It evaluates the PHP code, prints the output, and exits cleanly. No TTY required, no stdin gymnastics, no mystery silent failures.

This is a lifesaver for:

• CI/CD pipelines — seed data, run health checks, warm caches
• Docker automation — scripts that need to interact with Laravel in containers
• Cron jobs — quick data fixes without writing full artisan commands

Pro tip: for complex multi-statement logic, you can still pass a full PHP script to --execute. Just wrap it in quotes and keep newlines intact with $(cat <<'EOF' ... EOF).

Stop fighting with heredocs. Use --execute and move on with your life.

Ever debug a bug where your financial reports showed negative margins, only to discover you were mixing cached and fresh data in the same transaction?

I hit this in an API endpoint that calculated order profitability. The method fetched product costs fresh from the database (good!), but the companion method that grabbed retail prices was still using Redis cache (bad!). When prices changed, we’d calculate margins using old cached prices and new costs. Hello, mystery losses.

The fix wasn’t just “disable cache everywhere” — Redis cache is there for a reason. The real issue was inconsistent cache behavior within the same transaction.

Here’s the pattern that saved us:

class OrderCalculator
{
    public function calculateMargin(Order $order, bool $useCache = true): float
    {
        $cost = $this->getCost($order->product_id, useCache: $useCache);
        $price = $this->getPrice($order->product_id, useCache: $useCache);
        
        return $price - $cost;
    }
    
    private function getCost(int $productId, bool $useCache = true): float
    {
        if (!$useCache) {
            return Product::find($productId)->cost;
        }
        
        return Cache::remember("product.{$productId}.cost", 3600, function() use ($productId) {
            return Product::find($productId)->cost;
        });
    }
    
    private function getPrice(int $productId, bool $useCache = true): float
    {
        if (!$useCache) {
            return Product::find($productId)->price;
        }
        
        return Cache::remember("product.{$productId}.price", 3600, function() use ($productId) {
            return Product::find($productId)->price;
        });
    }
}

// In write operations (order creation, updates):
$margin = $calculator->calculateMargin($order, useCache: false);

// In read operations (reports, dashboards):
$margin = $calculator->calculateMargin($order, useCache: true);

The key insight: make cache behavior explicit and consistent. When you’re writing data or making financial calculations, all related lookups should use the same freshness guarantee. Add a useCache parameter (default true for reads) and disable it for writes.

Your future self debugging production at 2am will thank you.

Here’s a pattern I reach for any time I need temporary file operations in an artisan command or queue job: Storage::build().

Most Laravel developers know about configuring disks in config/filesystems.php. But what happens when you need a quick, disposable filesystem rooted in the system temp directory? You don’t want to pollute your configured disks with throwaway stuff.

The Pattern

use Illuminate\Support\Facades\Storage;

$storage = Storage::build([
    'driver' => 'local',
    'root' => sys_get_temp_dir(),
]);

// Now use it like any other disk
$storage->makeDirectory('my-export');
$storage->put('my-export/report.csv', $csvContent);

// Clean up when done
$storage->deleteDirectory('my-export');

This creates a filesystem instance on the fly, pointed at /tmp (or whatever your OS temp directory is). No config file changes. No new disk to maintain.

Why This Beats the Alternatives

You might be tempted to just use raw PHP file functions:

// Don't do this
file_put_contents('/tmp/my-export/report.csv', $csvContent);

But then you lose all the niceties of Laravel’s filesystem API — directory creation, deletion, visibility management, and consistent error handling.

You could also define a temp disk in your config:

// config/filesystems.php
'temp' => [
    'driver' => 'local',
    'root' => sys_get_temp_dir(),
],

But that’s permanent config for a temporary need. Storage::build() keeps it scoped to the code that actually needs it.

A Real-World Use Case

This shines in artisan commands that generate files, process them, and clean up:

class GenerateReportCommand extends Command
{
    protected $signature = 'report:generate {userId}';

    private Filesystem $storage;

    public function __construct()
    {
        parent::__construct();
        $this->storage = Storage::build([
            'driver' => 'local',
            'root' => sys_get_temp_dir(),
        ]);
    }

    public function handle()
    {
        $dir = 'report-' . $this->argument('userId');
        $this->storage->makeDirectory($dir);

        try {
            // Generate CSV
            $this->storage->put("$dir/data.csv", $this->buildCsv());

            // Maybe encrypt it
            $encrypted = $this->encrypt("$dir/data.csv");

            // Upload somewhere permanent
            Storage::disk('s3')->put("reports/$dir.csv.gpg", 
                $this->storage->get($encrypted)
            );
        } finally {
            // Always clean up
            $this->storage->deleteDirectory($dir);
        }
    }
}

The try/finally ensures temp files get cleaned up even if something throws. The command’s temp filesystem stays completely isolated from the rest of your app.

Storage::build() has been available since Laravel 9. If you’re still using raw file_put_contents() calls for temp files, give this a try.

If you’re logging records to a database table that has a unique constraint — say, tracking processed job IDs or idempotency keys — you’ve probably hit this at some point:

SQLSTATE[23000]: Integrity constraint violation: 1062
Duplicate entry 'abc-123' for key 'jobs_uuid_unique'

This typically happens when two processes try to insert the same record at roughly the same time. Classic race condition. And it’s especially common in queue workers, where multiple workers might process the same failed job simultaneously.

The blunt solution is to wrap it in a try/catch:

try {
    DB::table('processed_jobs')->insert([
        'uuid' => $job->uuid(),
        'failed_at' => now(),
    ]);
} catch (\Illuminate\Database\QueryException $e) {
    // Ignore duplicate
}

But there’s a cleaner way. Laravel’s query builder has insertOrIgnore() — available since Laravel 5.8:

DB::table('processed_jobs')->insertOrIgnore([
    'uuid' => $job->uuid(),
    'failed_at' => now(),
    'payload' => $job->payload(),
]);

Under the hood, this generates INSERT IGNORE INTO ... on MySQL, which silently skips the insert if it would violate a unique constraint. No exception thrown, no try/catch needed.

A few things to keep in mind:

• insertOrIgnore() will suppress all duplicate key errors, not just the one you’re expecting — so make sure your unique constraints are intentional
• On MySQL, it also bypasses strict mode checks, which means other data integrity issues might be silently swallowed
• If you need to update the existing record on conflict, use upsert() instead

Here’s the decision framework I use:

• “Skip if exists” → insertOrIgnore()
• “Update if exists” → upsert()
• “Fail if exists” → Regular insert() (and let the exception surface)

If you’re writing any kind of idempotent operation — event processing, job tracking, audit logging — insertOrIgnore() is the simplest way to handle the race condition without cluttering your code with try/catch blocks.