There's a failure mode in multi-server Laravel apps that never shows up as an error. It shows up as a customer asking why they got the same email three times. The cause is almost embarrassingly simple. Every server with a cron entry for schedule:run evaluates the whole schedule on its own. Each one asks which tasks are due this minute, gets the same answer, and runs them. Nothing coordinates between servers, because the scheduler has no idea the others exist. onOneServer() fixes that with a cache lock: the first server to start a task takes it, and the rest skip. The catch is that it's per task. The pull request behind Laravel 13.35 describes how people usually patch it: wrap the whole routes/console.php in a group. That works until someone adds a task outside the braces. The author's own phrasing was that it relies on everybody remembering it forever. A protection that depends on code structure and reviewer vigilance erodes silently, because an unprotected task behaves identically to a protected one on a single-server dev machine. 13.35 replaces the convention with a default. Schedule::alwaysOnOneServer() in your service provider covers every task, including ones defined after the call. What I'd actually spend time on is what it depends on. Closures without a name() are skipped silently, so they still run on every server with no warning, which is the exact symptom you were trying to cure. The lock lives in the cache, so a per-server file store means every server wins its own lock. And there's no per-task opt-out, so a schedule with real per-machine housekeeping shouldn't use the flag at all. The practical move is ten minutes of proof: grep your Schedule::call( closures, confirm the cache store, and log gethostname() from a before() hook on one real run. One hostname means it worked. The same release adds a clean way for long runInBackground() commands to stop during a deploy. That's a smaller change with the same shape: it only works if the command is written to be stopped. Full breakdown in comments.

There's a bug I keep seeing in AI features, and it never shows up as a bug. It shows up as a decision that was quietly wrong with full confidence. A moderation check flags a comment. Nobody asks how sure the model was. By the time the result reaches the if statement, a 51% guess and a 99% guess have both become the same true. The uncertainty didn't get handled badly. It got thrown away somewhere upstream, in a parsing step nobody examined closely, before your code ever had the chance to see it. I spent some time with a different approach this week. Jev, an AI model from TypeSafe, answers a typed yes/no question with a calibrated probability instead of text you then parse. The Decide with Jev course on Laravel News builds a content preflight checker around it, and the example makes the contrast concrete: a complete draft scores 0.96, a thin one that never gives a concrete step scores 0.02, and a genuinely mixed one lands somewhere that doesn't resolve to either. That mixed case is where it earns its keep. Instead of forcing it into true or false, the SDKs expose isTrue(), isFalse(), and isUncertain() with thresholds you set. Three outcomes instead of two, because the third one actually exists in the model's output. It also surfaced the cost, and it's real. You now have to decide what happens to the uncertain middle. Human review is the obvious answer, but not every feature can afford it at volume. And the threshold itself, whether 0.75 is the right line for denying a refund, isn't a technical default. It's a business decision about which mistake you'd rather make, and a boolean API let you avoid ever having to make it consciously. One honest caveat: the course is weeks old and the Laravel packages are unofficial. I found three independent wrappers published in the same short window. That's a sign of interest, and also of an ecosystem that hasn't settled yet. Full breakdown in comments.

Left a PR review comment recently that turned into a good reminder of why this whole category of Collection methods matters more than it looks like it should. The code: fifteen lines grouping shipment records by carrier, filtering out cancelled ones, building a summary array. A mutable $groupedByCarrier array, a manual isset() check before appending, a running count variable incremented inside the loop. Worked, mostly — except the summary count was off by one for any carrier whose first shipment happened to be cancelled, because the count-increment and the cancelled-check were in the wrong relative order, and nothing about a fifteen-line imperative block makes that kind of ordering bug visible on a read-through. Rewrote it as $shipments->reject(fn($s) => $s->cancelled)->groupBy('carrier'), two lines, and the bug was gone — not fixed, gone, because there was no accumulator left for the ordering mistake to hide inside. That's really the whole argument for reaching for named Collection methods reflexively: it's not about fewer lines for its own sake, it's that a hand-rolled accumulator is a fresh opportunity for a subtle bug every single time it's written, and a named method's accumulation logic is already tested, independent of whatever data happens to be running through it today. Went looking afterward for what else in the codebase was quietly reimplementing something that already has a name. Found a chunking-by-adjacency pattern hand-rolled as exactly what Laravel 13.30's new chunkBy() now does in one call — worth knowing precisely BECAUSE it's not groupBy() with a different name; it only groups items that are actually next to each other, which is exactly the property that made it useful for streaming a sorted query without loading everything into memory. Found a permissions check hand-wrapped in an array-store cache to memoize a tagged lookup within a request — exactly what 13.33's Cache::memo()->tags() now does directly, no wrapper required. None of these are exotic methods. They're the ones experienced Laravel developers reach for automatically and newer developers keep quietly reinventing, one foreach loop at a time. Full tour — every method paired with the loop it replaces — in comments.

Pulled a brand-new package into a project this week that's been hand-rolling Elasticsearch DSL arrays for a while, mostly to see how much of that raw-array pain it actually removes. Elastic Bridge, published on Laravel News this week, brings Eloquent-style fluent queries to Elasticsearch and OpenSearch. The pitch is straightforward: instead of a nested PHP array shaped like JSON — bool, must, match, term, filter, all as string keys three or four levels deep — you write HotelRoom::asBoolean()->mustMatch('city', 'accra')->filterByTerm('code', 'usd')->get(), reading like any other Eloquent chain. For the search my project actually does most — combining a full-text match with structured filters and a sort — it's a real improvement, not a cosmetic one. The raw DSL array's actual cost was never that it's impossible to write correctly. It's that a subtly malformed structure often still executes, just not the way you intended, and a 400 from the cluster with a DSL-specific error message is a genuinely worse debugging experience than a PHP type error would have been. The fluent chain removes an entire category of "nested this bracket one level too deep" mistakes. The part that actually surprised me was the testing story. fake() plus toQuery() lets a test assert on the exact generated query shape with zero running cluster required. Most raw-DSL codebases I've worked in either stand up a real Elasticsearch container for CI — slow, a genuine operational dependency for every test run — or just don't test the search layer at all and hope manual QA catches a malformed query first. Being able to unit-test "this chain of calls produces this exact DSL" is the single thing I'd want to keep even if I didn't adopt anything else from the package. Where it genuinely doesn't help: nothing in the documented API touches vector or semantic search. No knn() method, nothing for a dense_vector field. If your search feature is embedding-based similarity search, that half of the problem still needs raw DSL or the native client directly — this package's fluent vocabulary is built entirely around the classic keyword-and-filter model. Worth saying plainly since it shapes how I'd actually roll this out: it's days old, with a correspondingly small track record. Genuinely good for the classic case. Worth watching, not yet betting a critical search path on, for anything else. Full breakdown in comments.