Canceling a batch in Laravel is one line. Making sure your jobs actually respect that cancellation is the real work.

This week: canceling a running batch, skipping jobs with middleware, and using the finally callback to tell the difference between cancellation and failure. Episode is up.

How are you handling cleanup when a batch gets canceled mid-run? Curious whether people are leaning on the finally callback, model events, or something else entirely.

SkipIfBatchCancelled middleware on each job is the cleaner path. One line per job, no conditional logic scattered through your business code.

You can check $this->batch()->cancelled() inside a job and return early. It works. But doing that in every job is the kind of repetition that middleware exists to eliminate.

Everyone's talking about background AI agents running autonomous tasks. The boring infrastructure problem: what happens when you need to stop one mid-run. Laravel's batch cancellation is a good place to start thinking about this.

Bus::findBatch($id) is how you get a handle on a running batch. Worth putting a helper method on your model so you're not scattering that lookup across your codebase.

If you're learning Laravel, here's a new episode in the Getting Started with Laravel course. https://codecourse.com/courses/getting-started-with-laravel What course topic do you want to see next?

New Youtube Video! we're looking at something that comes up the moment you start building anything with job batches in Laravel — what happens when you need to stop mid-run. The episode drops Friday.

The pattern here is simple: interface defines the contract, job implements it, trait reads from it at dispatch, database stores it. Each layer does one thing.

At what point does a jobs table become a lightweight audit log? If you're storing state, title, description, and failure reasons — that's getting close. Where do you draw the line?

On failure, update the current task row with a description pulled from the exception. The infrastructure for this is already there once you have title and description in place — it's just one more column.

Job metadata isn't just for display. A failed_reason column on server_tasks lets you capture exception data at failure time and surface it later — without digging through logs.

Once your job titles are dynamic and stored at dispatch time, reloading the page is trivial. Iterate over server_tasks, output title — done. No front-end mapping, no hardcoded copy.

Set the server as protected in the constructor. You'll need it for the actual job logic anyway, so you're not adding the parameter purely for metadata — it's doing double duty.

This week was about attaching metadata to Laravel jobs so your UI doesn't need to hardcode anything. Title, description, dynamic values from the model — all stored at dispatch time. Full episode:

This week: storing metadata on queued jobs, enforcing a title/description interface, and making job labels dynamic from the model. The full episode is on YouTube:

Passing the server model into the job constructor gives you access to its data inside title() and description(). You can build strings like "Creating server #42" dynamically, rather than returning a static label.

When a job fails in your app, what does your UI actually show the user? An error code? A generic message? Something pulled from the exception? Interested in how people handle this.

In the CreateTaskTrait, pull title and description directly from the job instance before dispatching. Because the interface guarantees those methods exist, no null checks needed.

Hardcoding job labels in the UI is a maintenance problem. As soon as you rename a job class or change its behaviour, your UI copy is stale. Store the label where it belongs: on the job.

Interfaces in Laravel jobs aren't just structural. They let you make guarantees at the point of persistence — when you write to the database, you know the data is there.

A ServerJobInterface with title() and description() methods enforces a contract. Any job that implements it must provide both. No guessing whether the data exists when you go to store it.

New Episode today. www.codecourse.com

Do you store metadata alongside your queued jobs, or do you reconstruct job context from the payload at render time? Curious what people are actually doing in production.

Two new columns on the server_tasks table: title and description. Simple migration, but it unlocks dynamic job labelling across your entire queue pipeline.

Storing jobs in the database gives you more than state tracking. You can attach metadata — title, description — to each task and use it directly in your UI without hardcoding anything.

This week was about getting Dusk's database setup right — separate MySQL database, correct env file, migrations running cleanly. Easy to skip early on, annoying to fix later. Full episode if you missed it.

What's the part of your test setup you'd most want to go back and fix? Infrastructure, naming, structure — most projects have something.

Spent the week on Dusk database isolation — why in-memory SQLite doesn't work, wiring up a separate MySQL database, and what RefreshDatabase actually does in a browser test context. This one holds up.

The reason you want MySQL for Dusk tests rather than SQLite: e2e tests are supposed to replicate what a real user would hit. Switching the database engine is changing the environment in a way that matters.

At what point did you start taking test isolation seriously? For a lot of people it's after losing local data during a test run rather than before.

RefreshDatabase in a Dusk context runs migrations before each test and rolls them back after. Your testing database stays clean without you having to think about it.

phpunit.xml's in-memory SQLite config is great for unit and feature tests. Fast, isolated, no cleanup needed. Just don't assume it carries over to Dusk — it can't.

The simplest Dusk database setup: duplicate your existing MySQL database name, append _testing. Point your .env.dusk.local at it. Done. Separate data, same engine, no surprises.

Dusk can't use an in-memory SQLite database. It's running in an actual browser — the app has to serve real HTTP, which means a real, physical database on disk or in MySQL.

Do you bother matching your test database engine to production, or do you just use whatever's convenient? Genuinely split on whether it matters for most projects.

End-to-end tests should mirror real usage as closely as possible. Running Dusk against SQLite when your app uses MySQL in production is a subtle mismatch that can let things slip through.

New episode on Codecourse this week: Blade and view data — part of Getting Started with Laravel. codecourse.com

This week we're looking at database setup for Laravel Dusk — the parts that catch people out before they've written a single meaningful test. Episode drops Friday.

This week was about what happens before a route is matched — building a request object from PHP globals, binding it to the container via a service provider, and understanding what PSR-7 actually standardises. Full episode here if you missed it.

Most Laravel developers have never written $_SERVER directly. Is that a good thing, or does it mean we're missing something foundational?

Do you register things in service providers out of habit, or do you actually think through whether something should be shared, deferred, or bound to an interface?

This week we've been looking at how a PHP framework handles requests from the ground up — PSR-7, service providers, container bindings, superglobals. The episode that started it is on YouTube if you want to follow along.

Service providers are a good place to register infrastructure-level bindings. Request, config, database — things the rest of the app depends on. Keeps bootstrap logic in one place per concern.

PSR-7 is an interface contract. The package doesn't matter as long as it implements the interface. Your router, your container, your controllers — they all just depend on the interface, not the implementation.

If you don't understand what's in the request before your controller sees it, debugging gets harder. Knowing that getParsedBody() is just $_POST with structure removes a layer of mystery.

When you use shared on a container binding, you're telling it: resolve this once, cache the result, return the same instance on every subsequent call. Useful for anything that reads from globals — no point rebuilding it.

The request lifecycle isn't magic. Request comes in, router matches it, controller handles it, response goes out. Every PHP framework is a variation of that loop.

Building framework internals from scratch changes how you read framework source code. Has that ever been true for you — building something low-level making higher-level code click?